fix: drop the headless branch bash job logs never took - #71
Merged
Conversation
`bash_jobs_dir` had two answers: the session directory, or a per-process temp directory for a run without a session. The second one was never reached. `@session_id` starts as the sentinel `"headless"`, but the only caller is `build_agent`, and all four of its call sites assign the real session id immediately beforehand — headless runs included, since they have been opening a session since "session names, continue, context breakdown". The comparison was false every time it was evaluated, so the temp branch and the `rm_rf` that cleaned up after it were dead. The README, meanwhile, presented that branch as current behavior: "A headless run has no session, so its jobs use a per-process temporary directory that is removed with them." Verified against a real run — a background job under `smith run --yes` writes to `~/sessions/<id>/bash/bash-1.log`, and nothing appears in the temp directory. The sentence described something that had not been true for a while, and it was the sentence anyone would have read before wondering where their log went. Rather than swap one unreachable default for another, `@session_id` is now nilable and read through an accessor that raises. There is no run without a session; a value that stands in for one can only ever hide the day that stops being true. The other consumer, the hooks runner, goes through the same accessor and is built from `build_agent` as well, so it was never at risk either — it just no longer depends on the sentinel happening to be overwritten in time. Closes #69. 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
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.
Closes #69.
bash_jobs_dirhatte zwei Antworten: das Session-Verzeichnis, oder ein Per-Prozess-Temp-Verzeichnis für einen Lauf ohne Session. Die zweite wurde nie erreicht.Warum der Zweig tot war
@session_idstartete mit dem Sentinel"headless", aber der einzige Aufrufer istbuild_agent— und alle vier Aufrufstellen setzen unmittelbar davor die echte Session-Id, headless eingeschlossen (seit25dfef6„session names, continue, context breakdown" legt auch ein headless Lauf eine Session an):@session_idgesetzt inrun_headlessresume_headlessrun_plain_loopstart_session_looprun_tui_loopstart_session_loopDer Vergleich war also jedes Mal falsch, wenn er ausgewertet wurde. Der Temp-Zweig und die
rm_rf-Zeile, die hinter ihm aufräumte, waren unerreichbar.Was falsch dokumentiert war
Das README beschrieb genau diesen Zweig als geltendes Verhalten:
Verifiziert an einem echten Lauf (Stub-Provider, isoliertes
SMITH_HOME, eigenesTMPDIR): ein Background-Job untersmith run --yesschreibt nach~/sessions/<id>/bash/bash-1.log, im Temp-Verzeichnis erscheint nichts. Der Satz beschrieb etwas, das seit einer Weile nicht mehr stimmte — und es war der Satz, den man liest, wenn man sein Log sucht.Statt eines neuen Defaults
@session_idist jetzt nilable und wird über einen Accessor gelesen, der wirft. Es gibt keinen Lauf ohne Session; ein Wert, der für eine einsteht, kann nur den Tag verdecken, an dem das aufhört zu stimmen. Der zweite Konsument — der Hooks-Runner — geht durch denselben Accessor und wird ebenfalls ausbuild_agentheraus gebaut, war also nie in Gefahr. Er hängt jetzt nur nicht mehr daran, dass der Sentinel rechtzeitig überschrieben wird.Tests
crystal spec: 881 Examples, 0 Failurescrystal tool format --checksauber🤖 Generated with Claude Code