fix(bridge): keep pointer and loop files under --data-dir so a second bridge can't clobber the primary - #99
Merged
Merged
Conversation
…can't clobber the primary bridge.json, loops.json, loop-runs.json and session-registry.json were written to $HOME/.ftown unconditionally, ignoring --data-dir. A Solo test or a second bridge with its own --data-dir therefore overwrote the primary bridge's pointer file and deleted it on shutdown, orphaning the harness, and merged its loops into the primary's loops.json. New resolveFtownHome(dataDir): the default data dir (~/.ftown/data) still maps to ~/.ftown so the harness CLIs, which hardcode that path, keep working unchanged; any other --data-dir owns its own instance files under that directory. The pointer is written and unlinked at the same resolved path, so a custom-data-dir bridge can never delete the primary's bridge.json. env.json stays global (shared provider tokens), by design. Verified: with the default data dir every path is byte-identical to before; a scratch --data-dir run wrote the pointer and loops under the scratch dir and left the real ~/.ftown untouched. 769 bridge tests pass. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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.
Problem
bridge.json,loops.json,loop-runs.jsonandsession-registry.jsonwere written to$HOME/.ftownunconditionally, ignoring--data-dir(which only ever controlledbridge-id,refresh-token,solo/and the session store). So a Solo test or a second bridge started with its own--data-dir:~/.ftown/bridge.jsonand deleted it on shutdown, orphaning the harness and CLIs that hardcode that path;loops.json.This bit us in this very session: a Solo verification run deleted the running production bridge's pointer file.
Fix
New
resolveFtownHome(dataDir):~/.ftown/data) →~/.ftown, exactly as before, so the harness CLIs keep working with zero change;--data-dir→ that directory owns its ownbridge.json,loops.json,loop-runs.json,session-registry.json.The pointer is written and unlinked at the same resolved path, so a custom-data-dir bridge can never delete the primary's
bridge.json.env.jsonintentionally stays at~/.ftown(shared provider tokens). Path setters run at startup before any store is read; paths are computed per call, not cached at import.Verification
join(homedir(),'.ftown',<file>)— a test guards this so a revert fails.--data-dirrun wrote the pointer and loops under the scratch dir; the real~/.ftownwas untouched before and after.$HOME/.ftown/bridge.jsonunder a custom data dir, and the setter-before-read ordering is correct.Not in this PR
~/.ftown/workflows/<runId>is not rerouted (run ids are unique, low collision risk).env.jsonstays global by design.🤖 Generated with Claude Code