This repository was archived by the owner on Aug 8, 2026. It is now read-only.
windows: log the chain, because a stopped chain and a finished one look alike - #74
Merged
Conversation
…ok alike Task Scheduler records one Last Run Result on one task, so a chain that stopped after step 1 and a chain that ran all four are indistinguishable from it: the three steps that never executed have no representation anywhere. The wrapper now redirects every step to nightly.log with a timestamp header, and `nightly chain ok` is the only line that means all four ran. This also gives the `call` trap a symptom. That paragraph previously ended "there is no error and nothing in the log to look at", which was true when there was no log. Now the trace is the ABSENCE of a line: the log ends after the price output with no `nightly chain ok`. Rewritten to say so, since that absence is the whole reason for the log. Redirects are per-line rather than one redirect on a parenthesised block, and the reason is recorded inline so nobody tidies it: cmd expands %ERRORLEVEL% for an entire block at parse time, so every guard inside one would test the value from before the block started. The chain would then run all four steps regardless of failure while still reporting success, which is a worse version of the bug the guards exist to prevent. Avoiding it needs setlocal enabledelayedexpansion and !ERRORLEVEL! throughout; per-line redirection has no such trap. 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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Task Scheduler records one Last Run Result on one task, so a chain that stopped after step 1 and a chain that ran all four are indistinguishable from it: the three steps that never executed have no representation anywhere. The wrapper now redirects every step to
nightly.logwith a timestamp header, andnightly chain okis the only line that means all four ran.This also gives the
calltrap a symptom. That paragraph previously ended "there is no error and nothing in the log to look at", which was true when there was no log. Now the trace is the absence of a line: the log ends after the price output with nonightly chain ok. Rewritten to say so, since that absence is the whole reason for the log.Redirects are per-line rather than one redirect on a parenthesised block, and the reason is recorded inline so nobody tidies it away.
cmdexpands%ERRORLEVEL%for an entire block at parse time, so every guard inside one would test the value from before the block started. The chain would then run all four steps regardless of failure while still reporting success, which is a worse version of the bug the guards exist to prevent. Avoiding it needssetlocal enabledelayedexpansionand!ERRORLEVEL!throughout; per-line redirection has no such trap.Docs only. No
src/ortests/change, so the four suite totals inCLAUDE.mdare unmoved.🤖 Generated with Claude Code