anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[PR #11646] fix(opencode): atomic storage writes with retry/backoff + quarantine on Windows; tolerant reads #13877

New Issue
Open
opened 2026-02-16 18:18:42 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 18:18:42 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/anomalyco/opencode/pull/11646

State: open
Merged: No

What

  • Atomic write on Windows: temp → fsync(file) → rename → fsync(dir) with retry/backoff on open/rename.

  • Tolerant reads: retries on transient FS errors; if JSON is corrupt or retries exhaust, move to quarantine instead of crashing.

  • Quarantine: preserve data when rename/open is blocked (AV/sharing) and when JSON is malformed.

  • Tests: invalid JSON → quarantine; rename failure (target path is a directory) → quarantine.

Why (Windows)

  • Corporate AV often causes transient sharing violations leading to UV_UNKNOWN on open/rename (e.g. ...storage\part\msg_\prt_.json). This made storage unusable for some users (#8792).
  • This change keeps storage responsive by retrying transient errors and safely isolating bad/locked files.

Details

  • Retries: 6 attempts, exponential backoff (≈50ms → 1.6s).
  • Temp file name: .oc-<basename>.<pid>.<ts>.tmp in the same directory.
  • Directory/file fsync used where supported; failures are tolerated safely.
  • Quarantine path: storage/quarantine/<timestamp>/<relative-original-path>.json.

Verification

  • bun install and bun test: 789 passing, 0 failing.
  • Manual: on Windows with Defender enabled, confirm no hard crash, and that corrupt/locked files end up in quarantine when needed.

Trade-offs

  • Slight I/O overhead from fsync and retries, bounded and only on contention.
  • Creates a quarantine folder for recovery workflows.

Links

**Original Pull Request:** https://github.com/anomalyco/opencode/pull/11646 **State:** open **Merged:** No --- What - >Atomic write on Windows: temp → fsync(file) → rename → fsync(dir) with retry/backoff on open/rename. - >Tolerant reads: retries on transient FS errors; if JSON is corrupt or retries exhaust, move to quarantine instead of crashing. - >Quarantine: preserve data when rename/open is blocked (AV/sharing) and when JSON is malformed. - >Tests: invalid JSON → quarantine; rename failure (target path is a directory) → quarantine. Why (Windows) - Corporate AV often causes transient sharing violations leading to `UV_UNKNOWN` on open/rename (e.g. `...storage\part\msg_\prt_.json`). This made storage unusable for some users (#8792). - This change keeps storage responsive by retrying transient errors and safely isolating bad/locked files. Details - Retries: 6 attempts, exponential backoff (≈50ms → 1.6s). - Temp file name: `.oc-<basename>.<pid>.<ts>.tmp` in the same directory. - Directory/file fsync used where supported; failures are tolerated safely. - Quarantine path: `storage/quarantine/<timestamp>/<relative-original-path>.json`. Verification - `bun install` and `bun test`: 789 passing, 0 failing. - Manual: on Windows with Defender enabled, confirm no hard crash, and that corrupt/locked files end up in quarantine when needed. Trade-offs - Slight I/O overhead from fsync and retries, bounded and only on contention. - Creates a `quarantine` folder for recovery workflows. Links - Fixes #8792
yindo added the pull-request label 2026-02-16 18:18:42 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#13877
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?