Repository navigation
Sub-agent context ignores the latest snapshot: a mid-turn snapshot absorbs its messages and the sub-agent loses its task #2
Description
Follow-up to co-l#401 (mid-turn snapshot cadence) and #1. Reported by @vv7r while reviewing co-l#401 — the only one of his four findings not fixed in that branch, because it builds on a separate sub-agent compaction fix he has not sent yet.
Problem
buildContextMessagesFromEventHistory() expands the latest turn.snapshot, but buildSubAgentContextMessages() reads raw events only. When the cadence takes a snapshot while a sub-agent is running, that snapshot absorbs (and cleanupOldEvents() then prunes) the sub-agent's earlier messages, so its next request has lost both its task and its work. Qwen3-style templates then answer HTTP 500 No user query found in messages.
This is only reachable once the co-l#401 fixes land: before them a long sub-agent run gets no mid-turn snapshot at all, so the path is never exercised. It is the reason @vv7r called it a follow-up rather than a fix in co-l#401.
Direction proposed
- Share the snapshot expansion between both folds, instead of having
buildSubAgentContextMessages()read raw events. - Treat a replayed sub-agent summary message as its compaction boundary. The boundary cannot come from the replayed
context.compactedstub: that stub keeps only the window ids and timestamp — itssummaryis empty and it carries nosubAgentId, so it is indistinguishable from a main-turn compaction for anything filtering on that field.
Verification status
@vv7r ran fixes 2–4 together live (OPENFOX_SNAPSHOT_MAX_BYTES=1000000 to force the path): a 9-minute sub-agent run with 4 compactions, a mid-turn snapshot at 259 s pruning ~3,150 events, and the sub-agent finishing its 12 steps with the right output and no errors. That run does not isolate co-l#4 on its own — a standalone repro for this specific bug is not recorded in the co-l#401 thread.
Depends on
A separate sub-agent compaction fix (keeping a sub-agent's task in its context after a compaction) that @vv7r is sending as its own PR.
Related, different root cause
co-l#397 reports the same Jinja error from another cause: an Ollama chat request built with no role: "user" message at all (src/server/llm/ollama-native.ts). Same symptom, unrelated mechanism.
Activity
vv7r commentedon Oct 7, 2026
The sub-agent compaction fix this depends on is up: co-l#414 (based on today's develop, independent from co-l#401).
The commit you need is "keep the sub-agent's task in its context after a compaction": after a compaction the sub-agent's context now starts with its task, then the summary. Without it, a sub-agent loses its task at its first compaction and Qwen3-style templates answer HTTP 500 "No user query found" — live on develop, the sub-agent scenario stalled right there, while co-l#414 finished 20/20.
You can build #2 on top of that branch (vv7r:fix/compaction-small-context) until it lands.
mossaab commentedon Oct 7, 2026
Thanks @vv7r — implemented the fix on top of
vv7r:fix/compaction-small-contextas suggested.Two parts:
expandSnapshotEvents()so the top-level and sub-agent folds share the same snapshot expansion —buildSubAgentContextMessages()no longer reads raw events only.context.compactedstub (whose replayed form keeps only window ids/timestamp and nosubAgentId).Also added the standalone repro that was missing from the verification notes: a test forcing a mid-turn snapshot during a sub-agent run and asserting the sub-agent keeps its task and work.
Single commit (
8b6134b1) stacked on top of your branch — I'll rebase it ontodeveloponce co-l#414 lands.vv7r commentedon Oct 7, 2026
Tested 8b6134b live: it fixes it.
Setup: your fix/event-log-saturation (co-l#401 with the follow-ups) + co-l#414 + 8b6134b, local Qwen3-based model on llama.cpp (n_ctx 81,920, model set to 80,000 / 0.93),
OPENFOX_SNAPSHOT_MAX_BYTES=1000000so the cadence fires while the sub-agent works. Each run: one sub-agent running N commands with large outputs, then returning the N secret lines they hide.Two sub-agent compactions and two mid-turn snapshots in every run.
One heads-up for when both land: stacking it on co-l#401 conflicts in
expandSnapshotEvents. Your extracted version comes from develop's, so it drops co-l#401's exception that keeps a latertool.resultcompleting a tool call the snapshot left unresolved (the parent awaiting the sub-agent call). I resolved it by keeping your extraction with co-l#401's filter inside it;src/server/chatandsrc/server/eventspass with it (649 tests, yours included). Happy to send the resolved file if useful.mossaab commentedon Oct 7, 2026
Thanks for testing it live — great to see 8/8 and 20/20 with no HTTP 500.
Folded in the heads-up:
expandSnapshotEventsnow carries co-l#401's unresolved-tool-call exception (keeps a latertool.resultthat completes a call the snapshot left unresolved), so stacking on co-l#401 no longer drops that filter. Also ported the matching test (keeps a tool result that completes a tool call the snapshot left unresolved).Amended the same commit (now
9a19dffe) and force-pushedfix/sub-agent-context-snapshot. No need to send the resolved file — thanks though.