Skip to content

[fix][llm] preserve ToolCall.Extra when converting DO tool calls to eino schema - #631

Open
karthikchundi-commits wants to merge 1 commit into
coze-dev:mainfrom
karthikchundi-commits:fix/tool-call-extra-dropped-on-outbound-conversion
Open

[fix][llm] preserve ToolCall.Extra when converting DO tool calls to eino schema#631
karthikchundi-commits wants to merge 1 commit into
coze-dev:mainfrom
karthikchundi-commits:fix/tool-call-extra-dropped-on-outbound-conversion

Conversation

@karthikchundi-commits

Copy link
Copy Markdown

What

FromDOToolCall (entity.ToolCall -> eino schema.ToolCall, in backend/modules/llm/domain/entity/eino_convertor.go) dropped the Extra field. Both types define an identical map[string]any Extra field, and the reverse conversion ToDOToolCall already copies it correctly - this was a one-directional gap, not an intentional omission.

Why it matters

FromDOMessages/FromDOMessage (which call FromDOToolCall via FromDOToolCalls) are used directly as the outbound message input to chatModel.Generate/Stream in backend/modules/llm/domain/service/llmimpl/eino/llm.go - i.e. this conversion is applied to stored conversation history right before it's sent back to the model. Any provider-specific metadata a model attached to a prior tool call (stored in ToolCall.Extra by ToDOToolCall when that response first came in) was silently lost on every subsequent turn of a multi-turn tool-calling conversation.

Fix

Add the missing Extra: t.Extra assignment - a direct one-line mirror of what ToDOToolCall already does in the other direction.

Testing

Added a regression test case (TestFromDOToolCalls) with a populated Extra map, and extended the test's assertions to actually check Extra equality - the existing test case only covered the nil case (Extra: nil on both sides), which is exactly why this asymmetry wasn't caught before.

I don't have a local Go toolchain available in this environment, so I could not run go test/go vet myself. I verified the fix by reading the current cloudwego/eino source directly (schema/message.go) to confirm schema.ToolCall.Extra exists with a matching map[string]any type on both sides, rather than assuming. Happy to address any CI feedback.

Checklist

  • Read CONTRIBUTING.md
  • Added tests covering the fix
  • Ran go test locally (not possible in this environment - see note above)

…ino schema

FromDOToolCall (entity.ToolCall -> eino schema.ToolCall) dropped the
Extra field, even though both types define an identical
map[string]any Extra field, and the reverse conversion (ToDOToolCall)
already copies it correctly.

FromDOMessages/FromDOMessage - which call FromDOToolCall via
FromDOToolCalls - are used directly as the outbound message input to
chatModel.Generate/Stream in llmimpl/eino/llm.go, i.e. this is the
conversion applied to stored conversation history before it's sent
back to the model. Any provider-specific metadata a model attached to
a prior tool call (stored in ToolCall.Extra by ToDOToolCall when the
response first came in) was silently lost on every subsequent turn of
a multi-turn tool-calling conversation.

Added a regression test case with a populated Extra map; the existing
test case only covered the nil case, which is why the asymmetry wasn't
caught.

I don't have a local Go toolchain in this environment, so I could not
run `go test` or `go vet` - verified by reading the current eino
schema.ToolCall definition directly from cloudwego/eino's source
(schema/message.go) to confirm the Extra field exists with a matching
map[string]any type on both sides, rather than assuming.

Assisted-by: AI
Signed-off-by: Karth <karthik.chundi@gmail.com>
@CLAassistant

CLAassistant commented Aug 25, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants