Add call_id to LLM events for correlating requests

[vinibrsl]

When monitoring LLM events, consumers need to know which events belong to the same API call. Before this change, there was no way to correlate LLMCallStartedEvent, LLMStreamChunkEvent, and LLMCallCompletedEvent belonging to the same request.

[Vidit-Ostwal]

Hey @vinibrsl,
Not really sure, but this PR was merged which kind of does the same functionality
#3842

While streaming, there is no way to figure out which streaming chunks belongs to same chunk event, this PR add the response_id which is directly given by the provider.

Though this only targets LLMStreamChunkEvent
But I can extend it to LLMCallStartedEvent and LLMCallCompletedEvent as well.

[vinibrsl]

Hey @vinibrsl, Not really sure, but this PR was merged which kind of does the same functionality #3842

While streaming, there is no way to figure out which streaming chunks belongs to same chunk event, this PR add the response_id which is directly given by the provider.

Though this only targets LLMStreamChunkEvent But I can extend it to LLMCallStartedEvent and LLMCallCompletedEvent as well.

Thanks, @Vidit-Ostwal! That's great context.

Unless I'm missing something here, call_id serves a different purpose. When emitting LLMCallStartedEvent, for example, we don't have the response ID yet. Therefore, having some kind of ID that correlates all LLM events is still needed.

Let me know if you think we should consolidate somehow or if keeping both makes sense.

[Vidit-Ostwal]

Hey @vinibrsl, Not really sure, but this PR was merged which kind of does the same functionality #3842
While streaming, there is no way to figure out which streaming chunks belongs to same chunk event, this PR add the response_id which is directly given by the provider.
Though this only targets LLMStreamChunkEvent But I can extend it to LLMCallStartedEvent and LLMCallCompletedEvent as well.

Thanks, @Vidit-Ostwal! That's great context.

Unless I'm missing something here, call_id serves a different purpose. When emitting LLMCallStartedEvent, for example, we don't have the response ID yet. Therefore, having some kind of ID that correlates all LLM events is still needed.

Let me know if you think we should consolidate somehow or if keeping both makes sense.

This makes more sense,

The PR I add only targets the LLMStreamChunkEvent, which only if successful will be populated, but there are also other LLMStream events which needs to be coupled together, this PR adds that.

Said that, this does makes the previous PR a bit redundant, as response_id has smaller scope, than call_id. which is trying to do the same functionality.
lmk if you think we should drop it, can make a PR for that.

[vinibrsl]

Said that, this does makes the previous PR a bit redundant, as response_id has smaller scope, than call_id. which is trying to do the same functionality.

We could follow up by marking response_id as deprecated, and eventually drop it in the next version. Thanks!

[Vidit-Ostwal]

Said that, this does makes the previous PR a bit redundant, as response_id has smaller scope, than call_id. which is trying to do the same functionality.

We could follow up by marking response_id as deprecated, and eventually drop it in the next version. Thanks!

It was merged today, 8 hrs back.