[Bug]: Bounded thread snapshot returns the whole thread when its runs start from notifications (PR watch, task wakes) #17433

Activity

1. juliusmarminge commented on Oct 9, 2026

   

   juliusmarminge

   on Oct 9, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Thanks for the detailed numbers. I haven't run this against a large database; below is what current main (43f8a8de1) does on the paths you named, and it lines up with your reading.

   Notification-started runs don't count as turn starts

   • notificationTurnItem rewrites a user_message that carries a notification / delegatedCompletion into type: "notification", and strips inputIntent, createdBy, messageId and text in the process (L224-L234). The Orchestrator persists that rewritten payload at four call sites (Orchestrator.ts#L1839, L3971, L5506, L6409).
   • isThreadHistoryTurnStart only matches user_message with inputIntent turn_start / queued_turn, so a run whose root item is a notification isn't an anchor for either cap.

   SQL window (readCanonicalProjection)

   • turn_anchors takes up to THREAD_HISTORY_MAX_RAW_TURNS + 2 (152, with the cap at 150) user-message turn starts; user_anchors keeps the newest userTurnLimit + 2 user-created ones (12 for the first load, since maxUserTurns is 10).
   • boundary uses the oldest of those user anchors when there are enough of them, else the oldest of 152 raw anchors, else 0.
   • selected then uses LIMIT -1 as soon as user_anchors is non-empty (L2815). The rowLimit (77) only applies to histories with no user turn starts.

   That looks deliberate for ordinary threads: the policy comment says item/byte budgets only apply to histories without turn starts, so tool activity doesn't split a turn, and the raw-turn cap is meant to keep agent-driven turns from stretching the window. Both rely on every run starting with an anchor, though. In your thread the 3,759 PR-watch wakes are invisible to turn_anchors, so the raw cap seems unlikely to trip, the boundary lands on the 12th-newest user turn near the start, and LIMIT -1 returns everything after it. Nothing in this query bounds item count or bytes once a user anchor exists.

   In-memory path

   layerMemory.getThreadSnapshotWindow mirrors the SQL: it counts anchors with isThreadHistoryTurnStart, and when anchors exist it slices from a turn boundary (or rawStart, which is 0 below 152 anchors) with no row cap. selectOlderTimelinePage also drops the item/byte budget as soon as any user turn exists (L212) and only increments rawTurns on isThreadHistoryTurnStart, so older pages appear to have the same gap.

   Recent changes

   #17029 (merged) added these window CTEs and the user_message partial index in 060_ThreadSnapshotWindowIndexes.ts. #17387 (merged) changed parts of this query and buildBoundedThreadProjection's budget check, but the anchor predicate and the LIMIT -1 branch are unchanged on main. Open PR #16819 narrows LIMIT -1 to a positive boundary (the single-open-turn case); as far as I can tell it keeps the positive-boundary branch unbounded, so it likely wouldn't cover this thread on its own.

   Possible fixes (not mutually exclusive)

   1. Count notification-rooted runs as turn starts. Treat a run-root notification item (or preserve inputIntent on it) as a raw-turn anchor in isThreadHistoryTurnStart and in the turn_anchors SQL. The 152 raw-turn cap would then likely bound your thread. Caveats: the partial index only covers type = 'user_message', so the CTE would need an index that includes notifications; and it's worth checking that every notification item is a run root before relying on the type alone (your DB says yes, I haven't checked other delivery paths).
   2. Add an item/byte ceiling to bounded windows. Stop using LIMIT -1 for a bounded snapshot: cap rows (or bytes) even when user anchors exist, and hand back hasMoreHistory / a cursor for the rest. That would also guard against other anchor-poor histories, at the cost of sometimes splitting a turn, which the current policy tries to avoid.

   Related

   • #14701 — thread list read blocking the loop (different query).
   • #15365 — iOS reconnect loop when opening one thread; possibly the same symptom on a different cause.
   • #16819 — open, same LIMIT -1 branch, single-open-turn case.
   • #17029, #17387 — merged long-thread snapshot work.

   I didn't find a duplicate issue or an open PR that changes how notification-started runs are counted.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 9, 2026
3. EldarPolitkin commented on Oct 9, 2026

   

   EldarPolitkin

   on Oct 9, 2026

   Author

   More actions

   Opened #17441 with fix 1. It handles both caveats:

   • Index: wake anchors come from the newest 152 runs through the runs index and each run's root node, so there is no new index or migration.
   • Run roots: only a notification that starts its run counts. appendSteeringMessage can steer one into a running turn, and that one is excluded.

   On a copy of the database, the bounded first load of the reported thread went from 20,035 rows (61 MB, 6.6-8.4 s, server unresponsive about 3 s) to 75 rows (0.26 MB, 0.15-0.21 s). The PR has the full before/after.