[onechat] add tool progression events#233724
Conversation
|
/ci |
|
/ci |
1 similar comment
|
/ci |
| /** | ||
| * Defines all possible types for round steps. | ||
| */ | ||
| export type ConversationRoundStep<T = ToolResult[]> = ToolCallStep<T> | ReasoningStep; |
There was a problem hiding this comment.
Out of the scope of the issue, but I took the opportunity to remove the arguably not useful generics around conversation round types.
| export interface ToolProgressEventData { | ||
| tool_call_id: string; | ||
| message: string; | ||
| } |
There was a problem hiding this comment.
The new tool_progress event, having the tool_call_id to be able to identify which tool call it's attached to (similar to tool_result events), and a plain text message.
We can make that evolve into something more structured later, but for now, simpler is better, and full text is gonna be fine ihmo.
| if (sendEvent) { | ||
| const toolCallId = config.configurable?.tool_call_id ?? config.toolCall?.id ?? 'unknown'; |
There was a problem hiding this comment.
This one took time to find, but we do have the info of the tool_call_id within langchain wrappers, so we can "automatically" attach it to the underlying tool events.
| const toolNode = new ToolNode<typeof StateAnnotation.State.messages>(tools); | ||
|
|
||
| const selectAndValidateIndex = async (state: StateType) => { | ||
| events?.reportProgress(progressMessages.selectingTarget()); |
There was a problem hiding this comment.
Example of reporting progress for the search tool
| /** ID of this run */ | ||
| runId: string; |
There was a problem hiding this comment.
Was not being useful in any way after 6 months (it was meant to be used as "traceId" but we are using OTel directly for that now...), so removed it
| 'results' in step | ||
| ? JSON.parse(step.results).map((result: ToolResult) => { | ||
| if (step.type === ConversationRoundStepType.toolCall) { | ||
| return { | ||
| ...step, | ||
| progression: step.progression ?? [], | ||
| }; | ||
| } | ||
| return step; | ||
| }) | ||
| : [], |
There was a problem hiding this comment.
We'll switch to a more "elegant" way of populating non-backfilled fields later. But the idea is to add that progression: [] attribute during deserialization instead of making it optional on our domain model.
| ? JSON.parse(step.results).map((result: ToolResult) => { | ||
| if (step.type === ConversationRoundStepType.toolCall) { | ||
| return { | ||
| ...step, |
There was a problem hiding this comment.
why do we return step (outer object) instead of result in the map function? result is not used anywhere which feels like a bug?
I'm lost why we are mixing up results, step and progression under results, while in the ToolCallWithResult results and progression are on the same level
There was a problem hiding this comment.
Yeah it's definitely a bug, nice catch. I did too many things refactoring what Soren did while adding that backfilling for the progress array... I'll fix that, thank you
5b160c7 to
2f5bcf8
Compare
We can't have FTR tests for anything leveraging the chat API / an LLM atm, unfortunately. How I tested was:
|
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Async chunks
Public APIs missing exports
Unknown metric groupsAPI count
History
|
|
tested works well! |
## Summary Fix elastic/search-team#10841 - Add a new `tool_progression` type of event ```ts export interface ToolProgressEventData { tool_call_id: string; message: string; } ``` - Change the structure of persisted tool calls to include a list of progression events - Expose a dedicated event emitter to tool handlers for them to send progression events - Add example of such events for the `.search` tool <img width="944" height="303" alt="Screenshot 2025-09-02 at 20 09 15" src="https://github.com/user-attachments/assets/776a7b13-9d68-4255-9a5c-d27189db208e" /> --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary Fix elastic/search-team#10841 - Add a new `tool_progression` type of event ```ts export interface ToolProgressEventData { tool_call_id: string; message: string; } ``` - Change the structure of persisted tool calls to include a list of progression events - Expose a dedicated event emitter to tool handlers for them to send progression events - Add example of such events for the `.search` tool <img width="944" height="303" alt="Screenshot 2025-09-02 at 20 09 15" src="https://github.com/user-attachments/assets/776a7b13-9d68-4255-9a5c-d27189db208e" /> --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary Fix elastic/search-team#10841 - Add a new `tool_progression` type of event ```ts export interface ToolProgressEventData { tool_call_id: string; message: string; } ``` - Change the structure of persisted tool calls to include a list of progression events - Expose a dedicated event emitter to tool handlers for them to send progression events - Add example of such events for the `.search` tool <img width="944" height="303" alt="Screenshot 2025-09-02 at 20 09 15" src="https://github.com/user-attachments/assets/776a7b13-9d68-4255-9a5c-d27189db208e" /> --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Summary
Fix https://github.com/elastic/search-team/issues/10841
tool_progressiontype of event.searchtool