[hartmark]

…onses call-log summary

The openai-responses translator tracked tool calls in its own funcCallIds/ funcNames/funcArgsBuf bookkeeping without ever writing to the shared state.toolCalls Map that stream.ts's completion-log summary builder reads. Every openai->openai-responses translated stream with a tool call was persisted with finish_reason "stop" and no tool_calls, even though the actual SSE events sent to the client were correct.

Summary

• Describe the user-facing or operational change.

Related Issues

• Closes #
• Related to #

Validation

Run only the focused loop for what you changed — the full unit suite, Vitest, the
60% coverage gate, and the production build all run in CI on this PR (#8329):

• Focused tests for the change: node --import tsx/esm --test tests/unit/<file>.test.ts
• npm run lint
• Production-code changes include a new or updated automated test in this PR
• SonarQube PR analysis is green or any remaining issues are explicitly documented below

Tests Added Or Updated

• List every changed or added automated test file.
• If no production code changed, state that here.

Coverage Notes

• If this PR changes src/, open-sse/, electron/, or bin/, explain which tests cover the change.
• If coverage moved down in any touched file, explain why and what follow-up task will recover it.

Reviewer Notes

• Call out any risky areas, migrations, feature flags, or manual validation that reviewers should know about.

[diegosouzapw]

Thanks for tracking this down — nice catch. Confirmed locally: reverting just this file makes the new regression test fail (0 tool calls recorded vs the expected 1), and passes clean with your fix in place; the rest of the translator's existing test suite (17/17) and lint stay green too.

This is exactly the right fix — mirroring into the shared state.toolCalls Map that stream.ts's call-log summary already reads from the other response translators, gated correctly so a superseded/evicted tool call (the recordAsCompleted=false path) doesn't get mirrored. The config/quality/file-size-baseline.json bump is accurate for the new line count too.

One small optional thing we'll likely add on our side before merge: a changelog.d/fixes/ fragment per our CONTRIBUTING checklist (not CI-blocking, just our convention). No changes needed from you — this looks merge-ready as is. Thank you!

[diegosouzapw]

Merged into release/v3.8.49 — thanks @hartmark! Validated via a 26-PR local merge-train + per-file discriminator confirming zero regressions vs the pure release tip. 🙏