Dev backend /v2/chat-sessions returns 500 ResponseValidationError after 81d28b0 deploy

[Git-on-my-level]

Summary

After the dev backend deploy of commit 81d28b018875a8ea73bc41f32295e62cf70be899, the dev backend is returning 500s for chat session listing.

Evidence

Read-only dev health check on based-hardware-dev found:

• Project: based-hardware-dev
• Service: Cloud Run backend
• Revision: backend-81d28b0-1
• Commit: 81d28b018875a8ea73bc41f32295e62cf70be899
• Revision created: 2026-07-05T20:56:54Z
• Failing endpoint: GET /v2/chat-sessions?limit=50&offset=0
• Observed status: repeated 500
• Traceback root includes:

fastapi.exceptions.ResponseValidationError: 2 validation errors

Observed 500 clusters after deploy:

2026-07-05T21:21:56Z–21:22:00Z
2026-07-05T21:44:47Z–21:44:50Z
2026-07-05T21:56:53Z–21:56:57Z

Health/liveness is green, so this appears to be a response schema/model regression rather than a process outage.

Expected behavior

GET /v2/chat-sessions should return a valid response matching the declared FastAPI response model, not a 500.

Actual behavior

GET /v2/chat-sessions?limit=50&offset=0 returns 500 with ResponseValidationError on the newly deployed backend revision.

Suggested investigation

• Check the response model / serializer for /v2/chat-sessions.
• Compare response payload shape after the large merge against the FastAPI response schema.
• Add a regression test that exercises chat session listing with representative dev data.

Acceptance criteria

• /v2/chat-sessions?limit=50&offset=0 returns non-5xx for valid authenticated requests.
• Response payload validates against the declared schema.
• Regression coverage exists for the response shape that failed in dev.

[Git-on-my-level]

Additional current repro/evidence from Omi Beta v0.12.23:

• User-visible symptom: after sending a desktop chat message, Omi Beta shows the toast Something went wrong. Please try again.
• Current dev Cloud Run revision still affected: backend-ac1b3a6-1 (commit-sha=ac1b3a6ad6d3ef38d301711ef7f812f639683c8e, env=dev).
• Failing request at the screenshot time:
  • GET https://api.omiapi.com/v2/chat-sessions?limit=50&offset=0
  • User agent: Omi desktop omi/12026 ... Darwin/...
  • Status: 500
  • Latency: ~40ms, so this is immediate response serialization failure, not upstream LLM timeout.

Root cause is now narrowed: the /v2/chat-sessions endpoint returns at least one legacy/default-chat session document that matches the query but does not match ChatSessionResponse.

FastAPI response validation details from Cloud Logging:

fastapi.exceptions.ResponseValidationError: 2 validation errors:
{'type': 'missing', 'loc': ('response', 0, 'title'), 'msg': 'Field required', ...}
{'type': 'missing', 'loc': ('response', 0, 'starred'), 'msg': 'Field required', ...}

The offending returned document shape is legacy-ish: it has message_ids, file_ids, openai_thread_id, openai_assistant_id, plugin_id: None, updated_at, created_at, message_count, and preview, but lacks v2-required title and starred. Because database.chat.get_chat_sessions() filters only plugin_id == app_id and orders by updated_at, a legacy main-chat session with plugin_id=None and updated_at is included in the v2 list and then rejected by the declared response model.

Impact count from read-only dev logs for /v2/chat-sessions:

last 30m: 20 requests, 12 x 500
last 2h:  56 requests, 45 x 500
last 6h:  102 requests, 63 x 500
last 24h: 245 requests, 63 x 500

Suggested fix direction:

1. Make get_chat_sessions()/serializer tolerant of existing legacy sessions: either backfill/default title and starred in the response (title from preview or New Chat, starred=False) or exclude true legacy v1 sessions with a more explicit v2 marker.
2. Add a regression test where a returned Firestore chat session has plugin_id=None, updated_at, legacy message_ids, and is missing title/starred; endpoint must not 500.
3. Consider a one-time backfill for dev/prod data so old main-chat session docs get title and starred if the v2 endpoint is intended to list them.

[Git-on-my-level]

Follow-up surface sweep for schema-SSOT fallout:

I checked dev Cloud Run logs since the schema SSOT PR merge/deploy window (#8892, merge commit 81d28b018875a8ea73bc41f32295e62cf70be899, merged 2026-07-05T20:54:30Z) to see whether mobile or other app surfaces were also broken by response schema validation.

Findings:

• ResponseValidationError logs are only on Cloud Run service backend, revisions backend-81d28b0-1 and backend-ac1b3a6-1.
• The only user-facing 500s attributable to this backend schema validation issue are GET /v2/chat-sessions from Omi Apple clients (omi/... CFNetwork ... Darwin ...).
• Mobile-looking Flutter/Dart traffic (User-Agent: Dart/...) had no 5xx in the sweep window. The Dart errors were 401/403 auth/permission responses and one expected 404-ish firmware route, not schema-response 500s.
• Other 5xx in the same window were on desktop-backend provider routes (/v1/tts/synthesize 503 and /v1/proxy/gemini/... 504), which are separate desktop provider/backend capability failures and do not show ResponseValidationError.

Aggregates from read-only dev logs:

All Cloud Run 5xx since schema PR merge:
103 desktop-backend 503 /v1/tts/synthesize                         Omi Apple client
 33 backend         500 /v2/chat-sessions                           Omi Apple client (backend-ac1b3a6-1)
 33 backend         500 /v2/chat-sessions                           Omi Apple client (backend-81d28b0-1)
 26 desktop-backend 504 /v1/proxy/gemini/...:generateContent        Omi Apple client
  4 backend         503 /v3/memories/batch                          Omi Apple client

Flutter/Dart mobile-looking errors since schema PR merge:
- 255 total 4xx/5xx matching User-Agent `Dart/...`
- 0 were 5xx
- top statuses were 401/403 across /v1/conversations, /v1/goals/all, /v1/users/daily-summaries, developer webhook/key routes, etc.

Conclusion: based on dev evidence, this schema-SSOT regression appears confined to the v2 chat-session listing surface used by Omi Apple/desktop clients. I did not find evidence that mobile Flutter/Dart routes were broken by the same response-schema issue in dev logs.