End Session

When the user stops recording, the app signals session end; the server marks the session as ended and triggers ingest for any windows that have accumulated data but have not yet been processed.

Flow

1. User stops recording — The mobile app sends a POST request to /sessions/{sessionId}/end.

2. Session ID validation — sessionId is extracted from path parameters; missing returns HTTP 400.

3. Session state fetch — The full DynamoDB session record is read. A missing session returns HTTP 404.

4. Status update — The session's status field is set to "ended".

5. Pending window resolution — The Lambda computes which windows have data but have not yet triggered ingest:

6. If there are frames in the current (partial) window (frameCount > 0), that window is treated as completed.
7. The union of completedFrameWindows and completedAudioWindows forms the set of all data-bearing windows.

8. Windows already in ingestTriggeredWindows are excluded.

9. Ingest triggering — For each untriggered window (in ascending order), the Lambda attempts a conditional claim on ingestTriggeredWindows and then invokes the ingest Lambda asynchronously with { sessionId, userId, windowIndex, frameCount }.

10. Response — Returns { "ok": true, "ingestTriggered": <count> }.

Entry Point

• Lambda: main/server/api/sessions/end/app.py → lambda_handler
• HTTP method: POST /sessions/{sessionId}/end (API Gateway)

Dependencies

• DynamoDB: SESSIONS_TABLE_NAME
• Lambda: INGEST_FUNCTION_NAME

Error Cases