Recording observation
Resolve a stopped recording to one of seven states using the capture-session correlation triple.
A stopped recording resolves to exactly one of seven states. This page documents that state model.
Contract, not yet a live route
The observation endpoint - GET /v1/recordings/{captureSession}/observation, read-only - is a defined contract that this release does not yet expose as a callable route (it is not in the OpenAPI manifest). The state model below is stable and describes how a stopped recording is classified; treat the endpoint itself as forthcoming and do not depend on calling it yet. In the meantime, observe recording lifecycle through the recording.* events.
The seven states
| State | Meaning |
|---|---|
captureStopped | Capture ended. No save attempt observed yet. |
awaitingSave | A headless save ticket is outstanding, not yet committed. |
saved | A durable, committed save artifact exists for this capture session. Only this state certifies a save - a seeded meeting row is not a save. |
failed | A save was attempted and rolled back. The ticket is retained so a retry can reuse it. |
deleted | The meeting was deleted. A late save must not resurrect it, so a deleted meeting reports deleted even when a row still exists. |
timeout | A wait deadline elapsed with no terminal outcome. This never certifies a save - it's the absence of an answer, not a result. |
unknown | Cannot be determined - a missed event, or a restart with no durable artifact to fall back on. |
Correlation triple
Every observation is keyed on three ids: app instance, capture session, and save ticket.
- The app instance changes across a restart.
- The capture session and save ticket persist across a restart.
An artifact written by a previous app instance still satisfies a later query as long as the capture session matches (and the save ticket, when both carry one) - the app instance is deliberately excluded from the match. Two different capture sessions never satisfy each other, no matter what else lines up.
Restart semantics
A restart alone resolves to unknown unless a durable artifact narrows it to saved. Neither timeout nor unknown is a save - only saved is.
Not found vs unknown
A 404 (the standard error envelope, {"error":{"code":"not_found","message":"..."}}) means the capture session itself is unknown to Meetily. A 200 carrying "state":"unknown" means the opposite - the capture session is known, but its outcome isn't.
Last updated on