I Used Sentry to Expose a Silent Data-Loss Bug with Zero Errors Developer Abbas Mirza built Aether Canvas during OpenAI Build Week and discovered a silent data-loss bug in its workspace index persistence. The bug allowed two concurrent operations to overwrite each other's index updates, leaving workspace files unreachable without any error. Mirza fixed it by moving the read-modify-write transaction into the write queue and added deterministic before/after test harnesses. This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry. The front-page lesson:A green “success” proves that an operation finished. It does not prove that its result is still there. THE FOUR-MINUTE FIELD REPORT IN THIS EDITION The project · The incident · The patch · The safeguards · The signal SECTION I · THE PROJECT DESK Last month, I built Aether Canvas during OpenAI Build Week. It is a local-first Electron application where spatially grouping ordinary files creates the mini-app you need. Put a flight confirmation, hotel booking, budget, packing list, and city guide together, for example, and Aether turns the cluster into a living trip workspace with routes, spending, tasks, and places—all traceable to the source files. The idea is simple: Space is the prompt. But the build was anything but simple. It was a one-week hackathon, and those seven days had to cover validating the idea, designing the architecture, building the interface, connecting the AI workflow, testing the main experience, and preparing the final demo and presentation. We shipped a working product. We did not have enough time for deep concurrency and persistence stress testing. WHAT WE SHIPPEDA real local-first Electron product: spatial files, AI-generated workspaces, autosave, persistence, and a polished demo path. | WHAT THE CLOCK HIDThe main experience worked, but the one-week schedule left little room for simultaneous-operation and shutdown stress tests. | I also chose not to modify the original submitted repository before the winner announcement. I wanted the artifact being judged to remain exactly as submitted. Instead, I created a separate Bug Smash repository https://gitlab.com/abbasmir12/aether-canva-bugsmash , with the submission preserved at commit 3163641a https://gitlab.com/abbasmir12/aether-canva-bugsmash/-/commit/3163641a4cfbf13f551f4799cde37079ec6a5bb0 and tagged openai-hackathon-submission That gave me something unusually valuable for debugging: an untouched before state. SECTION II · INCIDENT REPORT Aether stores each workspace in its own JSON file and keeps a separate index containing the workspaces visible in the sidebar. The original implementation already used atomic temporary-file replacement and a write queue. At first glance, that looked safe. After tracing the workspace IPC calls, autosave path, rename path, and persistence service, I found the boundary was in the wrong place. ✓ WHAT WAS SAFEEach individual JSON replacement was atomic. A partial write would not leave behind a half-written index. | ✕ WHAT WAS NOT SAFEThe read and modification happened before the queued write, so two complete operations could still overwrite one another. | The queue protected an individual JSON write: js const operation = writeQueue.then async = { await fs.writeFile temporaryPath, contents, 'utf8' ; await fs.rename temporaryPath, targetPath ; } ; But updating the workspace index is not one write. It is a complete read → modify → write transaction: Create A: read index ── add A ── write A Create B: read index ── add B ── write B ▲ both writes succeed; A disappears from the index Two operations could read the same old index before either write entered the queue. Both would make a perfectly valid update. Both writes would complete successfully. The last valid-but-stale snapshot would win. No malformed JSON. No rejected promise. No crash for error monitoring to catch. Just a workspace file that still existed on disk but was no longer reachable from the application. I did not want to hammer the UI with clicks until I got lucky. I built deterministic before/after harnesses that run the same workloads against two real implementations: 🔴 BEFORELoads the authentic workspace service directly from submitted commit 3163641a with git show —not from a hand-written broken copy. | 🟢 AFTERLoads the repaired service from the Bug Smash branch and subjects it to the exact same operations and assertions. | The workload creates 40 workspaces simultaneously , then runs 20 autosave-versus-rename races . Each stage uses an isolated temporary Electron profile, opens the real desktop UI with the resulting data, and deletes that data after the window closes. My actual Aether spaces are never touched. npm run bugsmash:before -- --sentry npm run bugsmash:after -- --sentry The harness also refuses to present an inconclusive result: the before stage must reproduce the legacy failure, and the after stage must preserve every mutation. | Identical workload | Original submission | Repaired version | |---|---|---| | Workspace files written | 40 / 40 | 40 / 40 | | Workspaces reachable in the index | 1 / 40 | 40 / 40 | | Orphaned workspace files | 39 | 0 | | Autosave/rename trials that lost a mutation | 20 / 20 | 0 / 20 | SECTION III · THE PATCH DESK | CASE FILE | EVIDENCE | |---|---| Merge request | | 57fc12a — transaction-safe persistenceThe heart of the repair is intentionally small. A failure-safe exclusive queue now surrounds the complete public operation : js const runExclusive = async