Repository navigation
fix(vintage): set the two paths once, not nineteen times - #85
Merged
Merged
Conversation
Root cause of the 2026-07-31 missed capture, now confirmed. The task returned 9009, which is the preflight's "executable not found" branch, yet `where cotdata-vintage` and `where cotdata-schedule` BOTH resolve to exactly the expected path in the expected venv. Both facts are true because the wrapper repeated the two paths inline, NINETEEN times between them. A find-and-replace that misses one occurrence leaves seventeen correct and two wrong, and if either of the wrong ones is in the preflight block the run exits 9009 while every diagnostic an operator would think to run says the paths are fine. That is not an operator mistake worth diagnosing; it is a file worth fixing. The paths are now set ONCE into %COTDATA_STORE% and %VENV%, in two adjacent lines under a banner saying to edit exactly those and nothing else. All six executable invocations and every derived path read the variables. Occurrences went from 19 to 2. Two guards behind it: - Either variable still holding a placeholder exits 2 with an explanation, rather than proceeding to create a directory literally named "REPLACE_WITH_STORE_PATH\vintage" in the task's working directory and writing an entire capture into something nothing syncs. - The guard matches the PREFIX "REPLACE_WITH", not either full marker, and that is load-bearing rather than stylistic. Written the obvious way, as `if "%COTDATA_STORE%"=="REPLACE_WITH_STORE_PATH"`, a global find-and-replace of the marker (the likeliest way anyone edits this file) rewrites the guard's own comparison string, the test becomes "does the path equal itself", and it fires on every run. A guard destroyed by the exact operation it protects against is worse than no guard. Also documented while here: give the trigger a repeat-until-success like the COT release task already has, since a daily trigger with no repeat turns one failure into a lost day; and the first run after upgrading takes minutes and reports ~140,000 observations because the prior year has never been captured, which is a one-off rather than a fault. No library change; 257 tests still pass. Co-Authored-By: Claude Opus 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
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.
Root cause of the 2026-07-31 missed capture, now confirmed.
The task returned
9009, which is preflight's "executable not found" branch. Yetwhere cotdata-vintageandwhere cotdata-scheduleboth resolve to exactly the expected path in the expected venv.Both are true because the wrapper repeated the two paths inline, nineteen times between them. A find-and-replace that misses one occurrence leaves seventeen correct and two wrong, and if either wrong one is in the preflight block, the run exits 9009 while every diagnostic an operator would think to run reports the paths are fine.
That is not an operator mistake worth diagnosing. It is a file worth fixing.
Change
The paths are set once, in two adjacent lines under a banner saying to edit exactly those and nothing else. All six executable invocations and every derived path read the variables. Occurrences: 19 to 2.
Two guards behind it:
2with an explanation, instead of creating a directory literally namedREPLACE_WITH_STORE_PATH\vintagein the task's working directory and writing a whole capture into something nothing syncs.REPLACE_WITH, not either full marker, and that is load-bearing. Written the obvious way asif "%COTDATA_STORE%"=="REPLACE_WITH_STORE_PATH", a global find-and-replace rewrites the guard's own comparison string, the test becomes "does the path equal itself", and it fires on every run. A guard destroyed by the exact operation it protects against is worse than no guard. Verified by piping the file through the replacement and confirming the guard survives.Also documented
No library change. 257 tests still pass.
Generated with Claude Code