Hi! I noticed a small gap in Quill's otherwise thoughtful crash-safety story.
Quill deliberately records to CAF so audio already written remains readable if the process dies mid-meeting. A session only becomes eligible for resumed transcription once meta.json exists, though, and that file is currently written on a clean stop. This means a crash can leave usable mic.caf / system.caf files behind without a way for Quill to discover and process them on the next launch.
Would you be open to a focused crash-recovery flow?
My proposed scope:
- write a small atomic in-progress manifest when recording begins
- persist each track's first-buffer timestamp when it becomes available, without blocking the audio callback
- remove the manifest after a clean stop has produced the existing
meta.json
- on launch, recover manifests whose owner process is no longer running
- require at least one non-empty audio track, preserve whichever tracks survived, and then enqueue the session through the existing transcription pipeline
- mark recovered metadata explicitly and notify the user that an interrupted recording was rescued
- leave malformed, empty, or apparently active sessions untouched and log why
- keep existing completed-session and
meta.json behavior backward-compatible
I would keep this narrowly about making already-written audio discoverable—no changes to the transcription engine or recording UI beyond the recovery notification.
One design question before a PR: would you prefer the in-progress state as a separate recording.json sidecar that disappears on clean stop, or as an extended meta.json lifecycle? I lean toward the sidecar because it preserves the useful current invariant that meta.json means “ready for post-processing.”
Happy to implement this with focused recovery tests if the direction fits the project.
Hi! I noticed a small gap in Quill's otherwise thoughtful crash-safety story.
Quill deliberately records to CAF so audio already written remains readable if the process dies mid-meeting. A session only becomes eligible for resumed transcription once
meta.jsonexists, though, and that file is currently written on a clean stop. This means a crash can leave usablemic.caf/system.caffiles behind without a way for Quill to discover and process them on the next launch.Would you be open to a focused crash-recovery flow?
My proposed scope:
meta.jsonmeta.jsonbehavior backward-compatibleI would keep this narrowly about making already-written audio discoverable—no changes to the transcription engine or recording UI beyond the recovery notification.
One design question before a PR: would you prefer the in-progress state as a separate
recording.jsonsidecar that disappears on clean stop, or as an extendedmeta.jsonlifecycle? I lean toward the sidecar because it preserves the useful current invariant thatmeta.jsonmeans “ready for post-processing.”Happy to implement this with focused recovery tests if the direction fits the project.