Never Lose the Recording: Durability Lessons From One Lost Meeting
Free spatial notes
Put this workflow on an infinite canvas instead of another linear doc.
Start in the browser with no account. Create an account only when you want to sync what you made.
The Bug Report
"I just finished a meeting where I recorded the whole thing. When I clicked stop recording, I don't see the recording saved on the canvas. This was the second recording on this canvas."
That is the worst class of bug in a note-taking product. Not a crash, not a visual glitch — an hour of someone's meeting, gone, discovered only after the meeting ended and everyone left.
The parenthetical at the end turned out to matter a great deal.
What Was Actually Wrong
The architecture had a sequence problem. Stopping a recording kicked off a pipeline: finalize the audio, hand it to transcription, generate the capture package, place the card on the canvas, persist.
Persistence was near the end of that chain.
Which means any failure anywhere in the middle — a transcription error, a network blip, a timeout, a state collision from a second recording on the same canvas — lost the audio. Not "lost the transcript," which would be annoying. Lost the raw recording, the one irreplaceable artifact in the entire pipeline. Everything downstream can be regenerated. The audio cannot, because the meeting is over.
The second-recording detail exposed a state assumption: the flow had been built and tested for one recording per canvas, and a second one during the same session collided with leftover state from the first.
Rule One: Persist the Irreplaceable Thing First
The fix that mattered:
> Recordings are persisted immediately when stopped, before transcription or any AI action runs.
Stop means stop and save. Full stop. Everything else — transcription, summary, capture package, card placement, upload — happens afterward against durably stored audio, and every one of those steps is allowed to fail without costing the user anything they cannot recover.
This inverts the natural way you write the code. The natural way is a pipeline, because that reads well and matches how you think about the feature. The durable way is: capture, commit, then process. The commit is a hard boundary. Nothing before it is allowed to be optional and nothing after it is allowed to be load-bearing for the raw artifact.
Rule Two: Save As You Go
Persisting on stop is necessary but not sufficient, because it still assumes the user reaches "stop."
Real sessions do not always get there. The tab crashes. The browser is killed for memory. The laptop sleeps and the page is discarded. The user closes the wrong window. In every one of those cases, an hour of audio held only in memory is an hour of audio that never existed.
So the recording is written incrementally during capture, not assembled at the end. If the session dies at minute 47, there is 47 minutes of recoverable audio rather than nothing.
The general principle applies well beyond audio: anything that accumulates user input over minutes needs incremental durability. Long recordings, long forms, long editing sessions. If the value grows with time, so does the cost of losing it, and the probability of an interruption grows right along with it.
Rule Three: Bound Every Asynchronous Operation
A related failure from the same period: the AI actions modal could not be closed while processing, and AI requests had no timeout.
Combine those and a slow response is indistinguishable from a hang. The user is stuck in a modal they cannot dismiss, watching a spinner, with no way to tell whether waiting will help. The only escape is to reload the page — which, before the persistence fix, could also lose the recording.
Two changes:
- AI requests time out at 45 seconds rather than waiting indefinitely
- The modal stays closable during processing
Neither is clever. Both are the difference between a slow feature and a broken one. A user who can cancel and retry has a slow tool. A user who cannot has a tool that has taken their work hostage.
Rule Four: Show Progress Early
Live transcription now produces first output at roughly four seconds and refreshes every six.
This is a perception fix rather than a correctness fix, but it does real work. A recorder that shows nothing for thirty seconds is indistinguishable from a recorder that is not working, and the reasonable user response to a tool that appears not to be working is to stop it and start over — which is how you lose a recording to a feature that was functioning perfectly.
Early feedback is a durability feature, because it prevents the user from taking destructive corrective action.
Rule Five: Test the Second One
The bug report said "this was the second recording on this canvas," and that phrase deserves its own rule.
Most feature testing exercises the first invocation. First recording, first upload, first export. The second one is where leftover state, unreleased handles, stale identifiers, and half-cleaned listeners surface.
For any stateful feature, the minimum test matrix is: first invocation, second invocation in the same session, and invocation after an interrupted previous attempt. The third case is the one that finds the most bugs and the one nobody writes.
What This Cost to Fix
The recording durability work touched 23 source and test files. That number is worth stating plainly, because "persist earlier in the pipeline" sounds like a one-line change and it never is. Reordering when the durable write happens means every downstream consumer now receives a reference to stored audio rather than an in-memory object, and every one of them has to be updated.
Validation was 1,171 tests, TypeScript, and a production build before it went near main.
The Rules, Collected
If you build anything that captures user input over time:
- Persist the irreplaceable artifact first, before any processing that could fail
- Write incrementally, because sessions do not always reach a clean stop
- Bound every async operation with a timeout, and never trap a user in a modal
- Show progress early so nobody cancels a working operation
- Test the second invocation, and the one after an interrupted attempt
None of these are sophisticated. All five were violated by code that had passed review and worked correctly in every test we had written.
Record a meeting on a canvas and see where the transcript ends up.
30 days free. No credit card required.
Try the Meeting Notes template in OmniCanvas
Open a local canvas with the Meeting Notes layout ready to go — no setup or account needed.
Use the Meeting Notes TemplateStart locally, then sign up only to sync — or explore the interactive demo first.
Keep reading
A Private Meeting Recorder That Runs Entirely in a Browser Tab
We built recording, Whisper transcription, and AI summaries into our public demo with no server involved. Two problems nearly sank it: GPU memory and the cross-origin model cache.
TechniquesSpace to Pan, Except When You Are Typing: Keyboard Focus on an Infinite Canvas
Pressing space should pan the canvas. Unless there is a text cursor, in which case it should type a space. Getting this right is harder than it looks, and everyone gets it wrong at least once.
TechniquesThe Feynman Technique: Learn Anything with Spatial Notes
How to implement Richard Feynman's four-step learning technique on a spatial canvas: choose concept, teach it simply, identify gaps, simplify further. Show how the canvas layout makes each step visual.