fix: fsync state file before rename to survive crashes - #23
Open
ming-14 wants to merge 1 commit into
Open
Conversation
Write the goal state to a temp file and fsync it before renaming into place. Previously the temp file was never flushed, so a crash (power loss / BSOD) could leave an empty or partially-written state file that the plugin then failed to decode on every prompt.
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
If the opencode process terminates unexpectedly (crash, power loss, system restart), every subsequent prompt fails with:
Server log shows:
Root cause: the state file
goals.json(%APPDATA%/opencode-goal-plugin/goals.json) was found zero-filled — correct file size but all bytes\u0000.Why
writeStateEffect(src/state.ts) wrote to a temp file and immediatelyrenamed it into place without an intervening fsync:writeFile(tmp, JSON.stringify(state, null, 2) + "\n")rename(tmp, file)On crash, the rename metadata could be committed while the data blocks were still in the OS page cache and never flushed to disk, leaving a zero-filled file after restart. A leftover
.tmpfile with intact contents further confirms the write was interrupted.Fix
fsyncthe temp file before renaming it into place:Validation
bun run typecheck/bun run lint/bun run buildpassbun test: 93 pass; the only failing test (writes state with owner-only file permissions) is a pre-existing Windowschmodsemantics issue, failing before this changeAI Assistance: This pull request was created with the assistance of AI (opencode using deepseek-v4).