Feat/live ingestion job summary#91
Merged
Merged
Conversation
Previously the summary row was written exactly once, when the ingestion job finished. For the async submit/collect flow this means a long-running job (hours of polling) leaves no trace until completion — and no trace at all if it never finishes (e.g. a source stuck in has_pending()). Now the summary is persisted incrementally, for both flows: - A RUNNING row is written up front, right after the summary is created, so the job is observable from the start and a record survives even if the run never reaches its final yield. - A throttled progress snapshot (parent row only, ~every PROGRESS_SAVE_INTERVAL=100 tasks) is written after each sync batch and each async collect, keeping counters/state current mid-run. - The final write is unchanged (FINISHED + failed task summaries). Mechanics: - IngestionJobSummary.recount(): non-destructive counter recompute, reused by _set_ended() (which still truncates to failed tasks on end). duration now tolerates ended_at=None for live snapshots. - save_ingestion_job_summary(..., include_task_summaries=False): parent-only upsert so repeated live writes don't re-upsert the growing child rows. The upsert is keyed on ingestion_job_summary_id, so live writes update in place. Tests: test_live_job_summary covers both the sync find_datasets flow and the async submit/collect flow (RUNNING written first, live progress during the run, FINISHED last).
Follow-up on the live IngestionJobSummary writes: - Only FAILED task summaries are ever persisted as child rows (successful, ignored and skipped tasks are captured by the counters). This drops the include_task_summaries flag entirely: every write — live or final — persists the parent row plus any failed task summaries. A successful run writes no child rows at all, so live snapshots stay cheap, and failures now show up in the database as soon as they happen instead of only at the end. - test_live_job_summary now asserts on what is actually stored in the database (load_ingestion_job_summaries), reading the summaries back after each write to prove the RUNNING row + live progress are persisted mid-run (not just that save was called).
…errors StopProcessing stops a run gracefully (exit 2). FatalError is its counterpart for unrecoverable, non-retryable problems (e.g. a deactivated account): the source/loader raises it, ingestify propagates it out of find_datasets/collect instead of swallowing it as a skipped find_datasets, and the CLI exits non-zero so schedulers surface the failure. Claude-Session: https://claude.ai/code/session_01B5EfLJqoafjW1FhvkxGSmg
…sing controlled Two fixes on top of the FatalError work: 1. FatalError now persists the summary (as FAILED) before aborting. The loader has no finally to save an in-progress summary, so a bare re-raise lost the record entirely. It now set_exception + yields (so the loader stores it) + re-raises, at each point FatalError can surface. 2. The async submit/collect path had NO stop/fail handling at all: a StopProcessing (e.g. quota) or FatalError raised while collecting propagated without ever persisting the summary. Added a handler mirroring the sync path so StopProcessing saves a FINISHED summary (controlled stop) and FatalError a FAILED one. StopProcessing keeps its own controlled-stop semantics and is no longer folded into FatalError's re-raise clauses — only FatalError forces the hard stop. Claude-Session: https://claude.ai/code/session_01B5EfLJqoafjW1FhvkxGSmg
…-ingestion-job-summary
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.