fix(litellm): generate toolUseId when missing from provider

[Ratish1]

Description

LiteLLM returns null for the tool call id field, causing toolUseId to be None in the resulting event stream. This PR ensures that a valid UUID is generated and assigned to the tool call delta if the provider returns a missing or null ID.

Changes:

• Modified LiteLLMModel.stream to check for a missing id on the first tool delta and generate a new UUID if needed.
• Added a unit test test_stream_generates_tool_call_id_when_null to verify this behavior.

Related Issues

Fixes #1259

Documentation PR

N/A

Type of Change

Bug fix

Testing

How have you tested the change? Verify that the changes do not break functionality or introduce warnings in consuming repositories: agents-docs, agents-tools, agents-cli

• I ran hatch run prepare

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[mehtarac]

Thank you for the fix, @Ratish1, do you happen to have a code snippet or script that you used to verify and test this that a unique ID is being generated?

[Ratish1]

Thank you for the fix, @Ratish1, do you happen to have a code snippet or script that you used to verify and test this that a unique ID is being generated?

Hello @mehtarac , I wrote a unit test for this by mocking in this PR, is that enough?. Or should I do a script with the same mocking and like a model_id. Thanks

[Ratish1]

Hey @mehtarac , I'd like to follow up on my message in case you missed it. Thanks

[chaynabors]

@Ratish1 thanks for this fix. The repo restructured into a monorepo (strands-py/) which made the branch unrebaseable in place, so I opened #2949 with your patch carried forward to the new layout. Same approach, same test, just relocated. Credit to you in the PR body.