feat(managed-agent): Implement event replay (Stage D3) - #12840

[Suggestion] R1-1: The session enumeration is the one unbounded read in this otherwise fully-paged migration — SELECT DISTINCT tenant_id, session_id is materialized whole into a List<String[]>, so memory grows with the number of sessions rather than with any session's length, and a real probe ran the migration out of heap at 700k distinct sessions.

Everything else in V15 pages deliberately (5000-row event reads, 500-row write batches, with the comment "memory does not grow with a Session's length"), but the session list that drives those pages is unbounded. On a deployment with millions of distinct sessions the DISTINCT result set is fully materialized on-heap inside V15's single transaction (MySQL Connector/J additionally materializes a driver-side copy), the migration dies with OutOfMemoryError, and the service cannot start against that database until the heap is enlarged. Probe witness on a file-based H2 with 700,000 distinct sessions (1.4M rows):

Witness:

unmodified V15, -Xmx128m → PROBE migration COMPLETED in 197920 ms
unmodified V15, -Xmx96m  → PROBE migration FAILED after 247485 ms with
                           java.lang.OutOfMemoryError: Java heap space
                           (V14 had completed; the heap died in V15's phase)
paging comparison arm (enumeration via LIMIT + (tenant_id, session_id) > ?
cursor), same -Xmx96m    → PROBE migration COMPLETED in 303389 ms

Page the enumeration the same way the event reads are paged, carrying the last seen (tenant_id, session_id) as the cursor:

SELECT DISTINCT tenant_id, session_id
FROM managed_agent_event
WHERE (tenant_id, session_id) > (?, ?)
ORDER BY tenant_id, session_id
LIMIT ?

The fix's premises: the backfill cursor must keep sequence_id > ? (the last sequence actually read) and the cross-page continuation rule previousSequence == sequence - 1 ? previous : null, and ranged updates must not merge across sequence gaps — all pinned by the 6,000-event single-Part case in ManagedEventIdentityMigrationTest. The paging comparison arm above is the acceptance proof: it completes at the same heap where the unmodified form OOMs.

— glm-5.3-flash via Qwen Code /review (v0.24.6)

[Suggestion] R1-2: The web-shell stream's overflow fallback and non-zero-cursor resume are tested nowhere — the replay suite pins them only for the public stream, while streamWebShell is a ~70-line near-duplicate delivery loop that every server-side test drives only at afterSequence: 0.

The suite's javadoc promises "every stream must deliver each sequence exactly once and in order", and the production client really resumes with afterSequence: request.lastEventId (java-managed-agent-provider.ts) — but grep over the whole tree shows every web-shell stream drive site (the contract test's two, the replay test's one, and the four unit-test stubs) passes afterSequence: 0, and the overflow and Last-Event-ID resume tests open only publicStream. A regression confined to the web-shell loop — typically fixing streamPublic's overflow handling without mirroring it to its duplicate — passes the entire suite, and web-shell clients then observe gaps or duplicates after a hub overflow.

Witness:

not run — 缺测试本身即证据，由全树 grep 建立（web-shell 流所有服务端驱动点
afterSequence: 0；无 web-shell overflow 场景）

Parameterize overflowFallsBackToTheStoreWithoutGapsOrDuplicates (and the resume test) over both transports, opening the web-shell stream via POST with a non-zero afterSequence. Two constraints: the web-shell route takes afterSequence in the JSON body (WebShellStreamRequest, not a query parameter or header), and the mutant that proves the pin is dropping streamWebShell's delivery.overflowed() → reconcile = true branch — the web-shell variant must go red while the public stays green.

— glm-5.3-flash via Qwen Code /review (v0.24.6)

[Suggestion] R1-3: The no-cursor transcript description lists three excluded event kinds, but the implementation excludes four — item.reasoning.delta is missing from the prose (the sentence originates at openapi.json:762 and is generated into this file).

ManagedAgentStore.findControlEvents excludes exactly turn.accepted, item.output_text.delta, item.reasoning.delta and item.tool_call.updated, but the description says "other than input, text-delta and tool-call updates". The same document's own enum (L2936 ["input_text", "output_text", "reasoning"]) treats reasoning as a distinct category, so "text-delta" cannot be read as covering reasoning deltas. And the asymmetry bites: tail events after the Snapshot are unfiltered, so the same client sees reasoning deltas in the live stream but not on the initial page, with no sentence anywhere explaining it. Worst case: an integrator wrongly infers the session has no reasoning content.

Witness:

not run — 纯 prose/代码失配，两侧原文并排引用即证据：openapi.json:762 与
generated TS L45 列三类 vs ManagedAgentStore.java:719-723 的 NOT IN 四类清单

Fix it at the source (openapi.json:762 — add the fourth kind) and regenerate this file, keeping the sentence consistent with findControlEvents' exact four-kind list; the "every event after it" half is correct as written (tail events are unfiltered) and should not change.

— glm-5.3-flash via Qwen Code /review (v0.24.6)

[Suggestion] R1-4: The same three-vs-four exclusion defect is replicated verbatim in this design doc and its Chinese sister (§4.1) — fixing the contract sentence (the openapi description this doc mirrors) will not touch these two files, so after the fix the tracked bilingual docs remain wrong.

The implementation (ManagedAgentStore.findControlEvents, L719-724) excludes four kinds; this sentence (and the zh-CN doc's "除输入、文本增量与工具调用更新以外") lists three, omitting reasoning deltas. Each doc's own §4.2 table lists item.output_text.delta and item.reasoning.delta as distinct event types, so "text-delta" cannot be read as covering reasoning in-document either.

Witness:

not run — 纯描述性 prose 失配，两侧原文并排引用即观察（EN L84-86 / ZH L73）

Amend all texts together — this doc, the zh-CN sister's corresponding sentence ("推理增量"), and the openapi description — and keep the "and every later event" half unchanged (tail events really are unfiltered).

— glm-5.3-flash via Qwen Code /review (v0.24.6)

[Suggestion] R1-5: The overflow test's activation premise — that SessionEventHub.CAPACITY is smaller than the 600 events this test appends — lives only in this comment, pinned by no assertion; raising the capacity past 601 silently disarms the test while the suite stays green.

CAPACITY is private static final int CAPACITY = 512 (SessionEventHub.java:16) and appears nowhere in the test tree. If a future tuning change raises it to 1024, the 600 appended events all enqueue contiguously, await hands over live, reconcile never fires — and overflowFallsBackToTheStoreWithoutGapsOrDuplicates still passes with ids == range(1, last), while the store-fallback path it exists to guard has lost its only test. (The floor test would go red in the same scenario, but shaped like a replay/floor regression — misleading rather than diagnostic.)

Witness:

not run — 前提缺失由 grep 建立（测试树无 CAPACITY 引用；常量为 private）

Widen CAPACITY to package-visible (the test is in the same package) and pin the premise at the test's start:

assertThat(SessionEventHub.CAPACITY).isLessThan(OVERFLOW);

The mutation that proves the pin: temporarily set CAPACITY to 1024 — this new assertion must turn red while the rest of the suite stays green. Do not change the capacity's value or the drop semantics themselves; the fix only adds the dependency pin.

— glm-5.3-flash via Qwen Code /review (v0.24.6)

[Suggestion] R1-6: This test never asserts that emitter.resync stayed empty, although RecordingEmitter records resync frames in every test — the class javadoc's core mechanism distinction (hub overflow → silently fall back to the store; floor advance → exactly one resync) is pinned only on the floor side.

"Overflow produces ZERO resync frames" is asserted nowhere: grep over the sdk-java test tree shows the only .resync content assertion is the floor test's containsExactly. If a regression makes the hub-overflow branch also emit agent.session.resync_required — say someone "hardens" the overflow path with a resync — the whole suite stays green: the resync frame has no id: line so ids() is unaffected, and the exactly-once delivery assertion above passes while delivery stays exact. Afterwards every real client stall (overflow's normal trigger) forces a full snapshot reload instead of the cheap store catch-up this route promises.

Witness:

not run — 覆盖缺失由全文件通读 + grep 建立（.resync 断言仅 L213 一处）

The mutant that proves the pin: make streamPublic's overflow branch emit one resync frame without stopping delivery — this new assertion must go red while the other tests stay green. (One precision note from verification: a regression that reuses the existing resync() helper — which also completes the stream — WOULD be caught by the delivery assertions; the uncovered shape is precisely the resync-that-keeps-delivering one.)

— glm-5.3-flash via Qwen Code /review (v0.24.6)

[Suggestion] R1-7: This README sentence promises events keep the Item and Part identity they were accepted with and compresses the retraction into a mere "announcement" — but this PR's own retraction path rewrites identities and empties text, contradicting the machine-checked contract this doc summarizes.

retractContinuationOutput empties the retracted deltas' text and reassignIdentity (ManagedAgentStore.java:1833-1841) UPDATEs item_id/content_part_id for every event from the first retracted one on — retracted deltas lose their identity and later deltas are re-pointed at rebuilt Parts. The openapi this change ships spells this out ("which now have empty text and no item_id or content_part_id, and that later deltas may name other Parts"), as do both design docs; only the README collapses it to "announces". An integrator who treats the README as authoritative and caches each event's identity as immutable diverges silently after a Harness-recovery retraction.

Witness:

not run — 纯 prose 失配：README L36-37 vs openapi.json:2823/3807 与
reassignIdentity（L1833-1846 只 UPDATE 两列身份）逐行对照

Keep the "schema and projection versions are saved as accepted" half exactly as written — versions really are immutable (reassignIdentity UPDATEs only the two identity columns); the rewrite must not contradict openapi.json:2823 or the design docs.

— glm-5.3-flash via Qwen Code /review (v0.24.6)