Zero errors, one missing workspace: the failure your monitoring is built to miss

A developer writing up a DEV Summer Bug Smash submission went back into a hackathon project and found workspaces disappearing from its sidebar while every write reported success ^[1][11]. The failure produced no malformed JSON, no rejected promise and no crash, which means an error monitor sitting on that code path had nothing to report ^[12].

The project is Aether Canvas, a local-first Electron application built during OpenAI Build Week, where grouping ordinary files in space assembles a small workspace around them ^[2][3]. It shipped working, inside seven days that also had to cover idea validation, architecture, interface, the AI workflow, testing and the demo ^[4]. Deep concurrency and persistence stress testing did not fit ^[5].

Storage is simple: each workspace is its own JSON file, plus a separate index holding the workspaces the sidebar shows ^[6]. The original code already had two features that read as safe, atomic temporary-file replacement and a write queue ^[7]. The queue wrapped a single write, temp file then rename over the target ^[8]. But updating the index is not one write. It is a read, then a modify, then a write ^[9]. Two creates could each read the same stale index before either write entered the queue, each produce a perfectly valid update, and both complete; the last valid-but-stale snapshot wins, and the first workspace drops out of the index ^[10]. The workspace file is still on disk, just unreachable from the application ^[11]. Two successful operations, one surviving record ^[13].

That is the whole lesson, and the author states it plainly: a green success proves an operation finished, not that its result is still there ^[14]. Instrumentation bolted to the write call is telling the truth. Both writes happened. Nobody instrumented the invariant that the index contains every workspace.

The reproduction is the more transferable part of the work. Rather than clicking the UI until something broke, the author built deterministic before/after harnesses that run the same workload against two real implementations ^[15]: 40 workspaces created simultaneously, then 20 autosave-versus-rename races, 60 racing operations per stage ^[16][17]. Each stage runs in an isolated temporary Electron profile, opens the real desktop UI against the resulting data, and deletes that data when the window closes ^[18]. The harness refuses to return an inconclusive verdict, since the before stage must reproduce the legacy failure and the after stage must preserve every mutation ^[19]. Both stages can be run with a --sentry flag ^[20]. The supplied write-up stops before describing what Sentry itself reported, so treat the tooling claim in the headline as the author's, not as demonstrated here ^[1]. The comparison was possible at all because the submitted repository was left untouched, preserved at commit 3163641a and tagged openai-hackathon-submission ^[21].

The fix moves the boundary rather than adding machinery: a failure-safe exclusive queue now wraps the complete public operation, so every workspace mutation crosses it as one unit ^[22][23]. List, load, create, save and rename all pass through it ^[24], which means reads are serialised along with writes.

Worth watching: whether that serialisation costs anything visible once workspace counts grow, and whether the before/after harness becomes a standing gate rather than a one-off investigation. The portable action is to find every read-modify-write pair in your own system that a queue only half protects, and to ask what your dashboards would show if the write succeeded and the record did not survive.