Like TOOL_CALL_TRIGGER, but the call is one only the client can answer, so the chatbot
suspends the turn instead of running anything. The turn is finished by the tool-response
endpoint, whose request ends in the tool output and so gets the same text round.
Drives a search round whose completed output fails to parse as the chatbotβs search-output
schema: the same plain-text failure shape a real search backend can return, but on a
completed item rather than the in-progress placeholder every other scenario here uses.
The question CLIENT_TOOL_CALL_TRIGGER makes the mock ask. Has to pass the toolβs own
argument validation, which the chatbot runs before it suspends the turn.
The default roundβs answer, one delta per element. Each γx:yβ sourceγ is a citation marker the
frontend replaces with a link to the document it points at.
Opens the trigger !MOCK_TOOL_CALL:<tool_name>:<arguments>!, which makes the mock call any
registered tool, so exercising a new one end to end needs no scenario of its own here.
Anywhere in a chat message, this makes the mock answer with a function call instead of a
text answer, which is how a test drives the chatbotβs tool loop. The chatbot then runs the
tool and asks again with the tool output as the last input item, and the mock answers that
with a text round, completing a two-round turn.
A response to a request that asked for structured output instead of a stream: one whole JSON
object, whose text content is payload, the JSON the callerβs own schema describes.
A completed Azure AI Search output whose output is the same plain-text failure shape a real
search backend can return, rather than the AISearchOutput JSON the round otherwise expects β
on a completed item, unlike the in-progress placeholder search_and_text_round always
resolves through.
One assistant message as an output item, in the two shapes a round streams it in: content is
empty while the item is in progress and carries the whole text once it is done.
The events that stream one assistant message: the item, its content part, one event per delta,
and the finished item. output_index is the messageβs place among the roundβs output items, so
it depends on how many items the round emitted before this one.
The response object of a lifecycle event before the last one. Only id and a possible error
are read by the chatbot; Azure sends the full request parameters here as well. See
completed_response_object for the terminal event.
Wraps a roundβs own events in the lifecycle events every round shares: response.created,
which is where the chatbot picks up the response id it needs before the round is classified,
and the terminal response.completed.
What the search returns, as the JSON string Azure nests it in. Only get_urls is read: the
chatbot fetches each of those to build the answerβs citations, so both they and the hits come
from MOCK_DOCUMENTS, the documents the mock document storage serves.
Renders events as a Server-Sent Events body in the order given, stamping every data: object
with its own event name as type, the way Azure repeats it. The chatbot reads the event: line
to decide what the data: line after it means, so the pairing and the order are what make a
round parse as a tool call or as text.
A stream a proxy closed cleanly before Azure ever sent response.completed or
response.incomplete β the shape a clean EOF produces, as opposed to the idle-timeout error a
stalled connection produces.
A round that includes an output item kind the chatbot has no variant for, between the
reasoning item and the answer, the way an Azure feature this code predates would arrive.
What one round was billed for. cached_tokens is the part of the input Azure served from the
prompt cache, and the rest of it is what the round wrote there.