Overview

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
fix/openrouter-responses-call-id
696e8107 Merge 129aef0d40b623f3957a7ce7fdd097e78a885ad9 into 40b27309a9d50ddbb66e5621a052e0eb53eb1493
by Jan Kubica
Succeeded
fix/openrouter-responses-call-id
696e8107 test(openai-base): add a real round-trip guard for the call_id split The mock-based E2E suite cannot catch this class of bug. aimock maps an incoming `function_call.call_id` straight onto `tool_calls[].id`, so a request that uses the WRONG id consistently in both the `function_call` and its `function_call_output` still correlates and still passes. I confirmed this by running the new `openrouter-responses -- tool-calling` matrix entry against the pre-fix adapter source: it passes. Only a provider that knows the real item -> call_id mapping rejects the old shape. So the regression net has to be a unit test. `openai-base` had none for the full round trip: its request-mapping test hand-builds the assistant message including `metadata.itemId`, which assumes the very propagation that can break. Add a two-turn test that drives the real `chat()` agent loop with a server tool and asserts the second request carries both identifiers. This covers every adapter inheriting the base -- ai-openai, ai-grok, ai-bedrock, and the OpenAI-compatible adapter -- none of which override convertMessagesToInput. Verified it fails against the pre-fix source (`call_id: fc_item_1`, no `id`). Also stop labelling the output item id as `toolCallId` in the diagnostic log payloads of both Responses adapters. Now that the two identifiers differ, those fields reported the item id under the tool-call name. Each site logs `itemId`, plus `toolCallId: metadata.callId` where the metadata is in scope.
by Alem Tuzlak