Fix condor_history OperationalError on pre-rc21 provenance.db - #25
Merged
Conversation
task-30 (v0.1.0rc21) changed condor_history's schema (composite cluster_id/proc_id PK, new source/job_name/site/gpu_ids/status columns), but CREATE TABLE IF NOT EXISTS never touches an existing table. Any provenance.db built under v0.1.0rc19/rc20 kept its old cluster_id-only condor_history table, and every enrich-history/ enrich-jobad/scan --db call against it crashed with "OperationalError: no such column: source" -- hit in production immediately after upgrading to rc21. _init_schema now detects a condor_history table missing the `source` column and drops it before recreating. condor_history (unlike checkpoints/events) has no incremental ingestion state to lose -- every row is fully re-derivable by rerunning enrich-history/ enrich-jobad/scan --db -- so this is safe, and cheaper than telling someone to delete their whole provenance.db (which would also force a full rebuild of checkpoints/events). Logs a warning explaining what happened. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
condor_history's Schedd.history() scans its backing store sequentially per query regardless of constraint complexity, so batching cluster_ids into many small queries multiplies total scan work instead of reducing it. Adds per-batch timing to the progress output and exposes --batch-size on the CLI so this can be diagnosed and tuned without a code change; raises the default from 50 to 500. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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.
Summary
condor_history's schema (compositecluster_id/proc_idPK, newsource/job_name/site/gpu_ids/statuscolumns), butCREATE TABLE IF NOT EXISTSnever touches an existing table.provenance.dbbuilt under v0.1.0rc19/rc20 keeps its oldcluster_id-onlycondor_historytable forever, and everyenrich-history/enrich-jobad/scan --dbcall against it crashes withOperationalError: no such column: source— this is exactly what was hit in production right after upgrading to rc21._init_schemanow detects the stale schema (missingsourcecolumn) and drops+recreates just that one table before continuing.condor_historyhas no incremental ingestion state to lose (unlikecheckpoints/events, which track byte offsets/mtimes) — every row is fully re-derivable — so this is safe, and much cheaper than telling someone to delete their wholeprovenance.db.Test plan
uv run pytest tests/ -q— 278 passed, 2 skippedruff check/ty checkclean🤖 Generated with Claude Code