P1 [CRF-2] Prompts recorded before their interception ends never advance last_active_at, so the sort key is wrong for the normal production flow. (Netero)

Production order is RecordPromptUsage (inserts the prompt) during the interception, then RecordInterceptionEnded (sets ended_at): coderd/aibridgedserver/aibridgedserver.go:481 and :311. For a session's first interception, the prompt trigger's UPDATE matches no aibridge_sessions row (the row is only created when an interception completes), so the prompt timestamp is silently dropped. The interception trigger then seeds last_active_at from started_at; its GREATEST only ever compares started_at values and never sees the prompt's created_at.

Reproduced empirically by Netero: interception in-flight, prompt at 00:05, interception ended at 00:06 yields last_active_at = 00:00 (started_at), where the old query returned 00:05. The trigger comment claiming the interception trigger's GREATEST "keeps whichever timestamp is later" is false. Every single-interception session, and the first interception of every session, sorts by start time instead of prompt time, diverging from the column's own documented semantics and from pre-PR behavior.

🤖

Good catch, confirmed.

Rather than patch it, I'd drop aibridge_user_prompts from the sync path and define last_active_at as MAX(ended_at) or MAX(started_at).

That removes the prompt trigger and the backfill's LEFT JOIN, and makes this bug structurally impossible: it exists only because prompts arrive before the session row does. Ordering barely changes.

What do you think?

I changed my mind, fixed here: 7e5b180

P1 [CRF-3] Retention purge orphans aibridge_sessions rows, and the list query then fails to scan NULL aggregates into non-nullable Go fields. (Netero)

DeleteOldAIBridgeRecords deletes interceptions but nothing deletes the corresponding aibridge_sessions row: no DELETE trigger exists and the purge CTE does not touch the table. Reproduced: after deleting a session's interceptions, the session row survives and the page lateral's MIN(ai.started_at) / MAX(ai.ended_at) return NULL.

ListAIBridgeSessionsRow.StartedAt/EndedAt are non-nullable time.Time, so scanning NULL fails and the entire ListAIBridgeSessions call errors; the sessions list endpoint breaks once retention purges any session still on a page. Fix: delete session rows whose interceptions are purged (a DELETE trigger or an extra CTE in DeleteOldAIBridgeRecords).

🤖

Fixed here: e320c5c

P2 [CRF-5] 165 lines of trigger, upsert, and backfill logic plus rewritten list-query semantics ship with zero new tests (diff test density 0.0%). (Netero)

The two proven bugs above (prompt ordering, purge orphans) are exactly the paths no test exercises: TestAIBridgeListSessions inserts data in an order that avoids the prompt race, and no test covers purge interaction or the backfill.

At minimum: a test inserting a prompt before UpdateAIBridgeInterceptionEnded, a test running DeleteOldAIBridgeRecords then listing, and a backfill assertion in the migration fixtures.

🤖

P3 [CRF-6] The trigger, the backfill, and the display query disagree on which client a session has. (Netero)

The trigger keeps the first non-NULL client (COALESCE(existing, EXCLUDED)); the backfill and the outer display lateral keep the first client ordered by started_at, id, which can be NULL even when later interceptions have one.

A session whose first interception has NULL client filters as client=X (trigger-maintained) but displays as empty, and the same session backfilled stores NULL and does not match the filter. The old filter matched any interception's client. Pick one rule and use it in all three places.

🤖

We have an invariant that one session = one client. I don’t think it’s explicitly enforced, but it shouldn’t break. And if it does, I’m fine with minor issues—the important thing is that we shouldn’t return a 500 or panic.