fix(core): on_llm_new_token correct casting for .content to string

[keenborder786]

• Description: The on_llm_new_token function should only accept values of type string. However, the .content attribute can sometimes be a list, so it’s unclear why it wasn’t being cast to a string. This PR addresses that by adding the necessary type casting.
• Issue: anthropic: on_llm_new_token gets list of dicts instead of string for Anthropic models #30703

[codspeed-hq]

CodSpeed Performance Report

Merging #33498 will not alter performance

_{Comparing keenborder786:fix/on_llm_new_token (313b3d0) with master (d9e659c)}

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

Summary

✅ 13 untouched
⏩ 21 skipped¹

Footnotes

1. 21 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[keenborder786]

@eyurtsev

[ccurme]

do we want to json.dumps the content or just call chunk.message.text as the original issue proposed?

my bias is to do chunk.message.text, which will represent tokens of text content. it will miss tokens from reasoning, tool calls, and other content, but I don't think on_llm_new_token was designed to support these well. so my thought is to go with well-defined behavior for now.

[eyurtsev]

This requires very careful design review. It's possible that the type is wrong and the callback handler actually needs to support all content not just text. We need to check how things are wired

[keenborder786]

@eyurtsev right now it only supports text, do you mean we need to update on_llm_new_token itself to support all type of objects?

[ccurme]

Yeah, I think @eyurtsev's point was that given how often this is used it's likely that coercing to string will break things, and that the original type is actually not accurate. But we'd need to scope the change. Closing for now to continue discussion on the original issue.