Skip to content

fix(vintage): set the two paths once, not nineteen times - #85

Merged
mspinola merged 1 commit into
mainfrom
claude/vintage-single-path-edit
Aug 1, 2026
Merged

mspinola merged 1 commit into
mainfrom
claude/vintage-single-path-edit

Conversation

@mspinola

@mspinola mspinola commented Aug 1, 2026

Copy link
Copy Markdown
Owner

Root cause of the 2026-07-31 missed capture, now confirmed.

The task returned 9009, which is 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 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:

  • A placeholder left in either variable exits 2 with an explanation, instead of creating a directory literally named REPLACE_WITH_STORE_PATH\vintage in the task's working directory and writing a whole capture into something nothing syncs.
  • The guard matches the prefix REPLACE_WITH, not either full marker, and that is load-bearing. Written the obvious way as if "%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

  • Give the trigger a repeat-until-success, as the COT release task already has. A daily trigger with no repeat turns one failure into a lost day.
  • The first run after upgrading takes minutes and reports ~140,000 observations, because the prior year has never been captured. One-off, not a fault.

No library change. 257 tests still pass.

Generated with Claude Code

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>
@mspinola
mspinola merged commit e3a8528 into main Aug 1, 2026
5 checks passed
@mspinola
mspinola deleted the claude/vintage-single-path-edit branch August 1, 2026 13:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant