[hartmark]

Summary

Extracted from PR #9439 (agentic conversation tracking) — these are general SSE/dashboard bugs affecting the "Provider Response" panel for any streamed request, not specific to conversation tracking. Splitting them out for independent, faster review.

Three related bugs, fixed in sequence:

1. Stale/truncated summary reconstruction (fix(backend): dashboard log viewer shows stale provider response for long streamed responses #9315). open-sse/utils/stream.ts reconstructed the dashboard's "Provider Response" summary from buildStreamSummaryFromEvents(providerPayloadCollector.getEvents(), ...) — but getEvents() only returns whatever survived the collector's maxEvents/maxBytes cap. Once a stream exceeded it (easy with a reasoning + tool-calling model), everything after the cutoff (final finish_reason, tool_calls, rest of reasoning_content, usage) was silently dropped from the reconstruction, even though the client actually received the correct, complete response.

   Fix: streamPayloadCollector.ts's per-format summary builders are now also available as incremental reducers (ingest one chunk at a time, finalize at the end). createStructuredSSECollector accepts a format/fallbackModel and feeds the reducer on every push() — including chunks later dropped from the retained event array — via a new getSummary() method.

2. Client format used instead of provider format. providerPayloadCollector was keyed on sourceFormat (the CLIENT's wire format) instead of targetFormat (the PROVIDER's). Whenever a request translates between two different formats — e.g. a Responses-API client routed to a plain-OpenAI-chat-completions upstream (the common OpenClaw/opencode-zen combo shape) — the reducer picked for sourceFormat could never recognize the provider's actual raw event shape, so it never left its empty initial state. The dashboard's "Provider Response" panel permanently showed output: [] while "Client Response" correctly showed full content, reading as if the two panels simply disagreed about the same request.

   Confirmed live via a wire-level pcap capture cross-referenced against a dashboard log entry: the actual response was complete and correct — this was purely a logging/summary bug, never a wire-format bug.

3. Missing object marker on the fallback summary. The responseBody-as-summary fallback path (used when the format doesn't need the events-derived summary) never set object: "chat.completion" at all, caught by this PR's own new regression test.

⚠️ base-red inherited: #9985

Test plan

• TDD: regression tests in tests/unit/stream-payload-collector.test.ts and tests/unit/stream-utils.test.ts — confirmed failing against the pre-fix code, passing after.
• tests/unit/stream-utils.test.ts + tests/unit/stream-payload-collector.test.ts + tests/unit/stream-payload-collector-9315-truncated-provider-response.test.ts — 70/71 passing (the one remaining failure, "passthrough splits mixed reasoning and content deltas", is a pre-existing v3.6.6-era test confirmed failing identically on a pristine upstream/release/v3.8.50 checkout — unrelated to this change).
• npx tsc --noEmit — clean for all changed files (pre-existing unrelated errors elsewhere confirmed identical to upstream, zero diff at those lines).
• npm run lint — clean.

[diegosouzapw]

Reviewed via TDD probe against a fresh worktree off release/v3.8.50 (merge-base 1 commit behind tip, no base-drift). All three claimed bugs verified independently: reverting the prod diff makes the corresponding new regression test fail with the exact symptom described (getSummary is not a function for bug 1; providerPayload.object undefined instead of 'chat.completion' for bugs 2+3 combined). Full suite green hermetically: stream-utils.test.ts 52/52, stream-payload-collector*.test.ts 19/19, plus the untouched sibling request-log-payloads.test.ts (still exercises getEvents()) unaffected at 9/9. The apparent -366 line deletions are reformatting noise, not real removals -- confirmed buildOpenAISummary/buildResponsesSummary/buildClaudeSummary/buildGeminiSummary all still exist, still internal-only, no lost callers. Raw eslint shows 17 hits but they match config/quality/eslint-suppressions.json's frozen counts exactly (1 pre-existing no-restricted-syntax + 16 pre-existing no-explicit-any) -- zero new violations, npm run lint is genuinely clean. tsc --noEmit full run: zero errors touching the changed files. Nothing mandatory before merge. Optional follow-up: open-sse/utils/streamEmptyChoices.ts:98 (rejectEmptyChoicesStream) still reconstructs its provider summary via the old getEvents()-based path rather than the new getSummary() reducer -- low impact since that path only fires when no valuable chunks were forwarded, but worth a small consistency pass in a later PR.

---

Note: the base-red that was failing this PR's CI (#9985) was drained today — base-reds PR #10213 just merged into release/v3.8.50. A rebase/sync onto the current tip should bring your checks green.

[diegosouzapw]

Merged — thanks @hartmark! All three Provider Response summary bugs verified independently; the live per-format reducer is a real improvement over the capped getEvents() reconstruction.