GeezerVison

Summary

TemporalStreamingModel already streams text deltas and reasoning summary deltas to Redis via StreamingTaskMessageContext, but ResponseFunctionCallArgumentsDeltaEvent was being silently buffered into function_calls_in_progress[...]['arguments'] with no per-delta publish. Consumers only saw the completed tool call surface later (after the activity returned, via downstream hooks if any).

For write-heavy tools — write_file, apply_patch, anything that puts a 2–20KB string into a single argument — the model spends multiple seconds generating the argument body, and the UI sees nothing until the entire activity finishes. The result is a frozen UI followed by an abrupt jump when the activity returns.

This PR threads tool-call argument deltas through the same streaming machinery used for text and reasoning, riding on the CoalescingBuffer + StreamingMode infrastructure added in #333. The buffer's merge helpers already key on tool_call_id for ToolRequestDelta, so coalescing, mode dispatch, and opt-out are inherited from existing infra.

Design

TemporalStreamingModel now opens a streaming_task_message_context per function call (keyed off the call's output_index), with initial_content=ToolRequestContent(...) and the model's configured streaming_mode. Three event handlers participate:

End-of-loop cleanup defensively closes any function-call contexts that didn't see a Done event (truncated stream or mid-stream exception).

ModelResponse output is unchanged: output_items still receives the same complete ResponseFunctionToolCall. Activity determinism is unaffected — streaming is a side effect.

What this does NOT change

• Text and reasoning streaming paths are untouched.
• StreamingMode is already the on/off knob. No new flag. streaming_mode="off" suppresses tool-arg deltas the same way it suppresses text deltas. "per_token" publishes immediately; "coalesced" (default) batches at 50ms / 128 chars.
• TemporalStreamingHooks.on_tool_start is unchanged. It still fires after the activity returns and still emits a ToolRequestContent Full message via the stream_lifecycle_content activity. See Caveats.

Caveats

1. Overlap with TemporalStreamingHooks.on_tool_start. Users who pass TemporalStreamingHooks to Runner.run will now see two persisted task_messages per tool call: one created by the model (delta stream + final Full) and one created by the hook (Full only). Both land on the same Redis topic task:{task_id} with different parent_task_message.ids, so a default UI will render two cards for the same logical tool call.

   This needs a follow-up to decide which path owns the canonical ToolRequest emission. Options for review discussion:

   • Silence on_tool_start's Full emit when the model is also emitting (auto-detect via a workflow-instance flag, mirroring how _task_id / _trace_id are threaded today).
   • Remove on_tool_start's Full emit entirely in a follow-up major bump (the model becomes the single source of truth for ToolRequest events).

   Until that follow-up, users who want streamed tool args without duplicate emits should subclass TemporalStreamingHooks and override on_tool_start to a no-op.

2. Coalescing windows still apply. With the default 50ms / 128-char window, tool args render in ~50ms-granularity chunks rather than per-token. This is the same tradeoff already made for text streaming in perf(streaming): coalesce per-token publishes to Redis (50ms / 128-char window) #333, and the right default for write-heavy tools (UX value is "watch the artifact appear", not "see each token").

3. Malformed argument JSON. If the model produces invalid JSON for the args (truncated stream, hallucinated structure), the path logs a WARNING and emits arguments={} in the final ToolRequestContent. The raw delta stream is preserved on the consumer side regardless — only the structured final view falls back.

Test plan

• Two new unit tests in test_streaming_model.py::TestStreamingModelFunctionCallArgsStreaming:
  • Happy path: well-formed args produce one streaming context opened with ToolRequestContent, one StreamTaskMessageDelta(ToolRequestDelta) per ArgumentsDelta event preserving the delta text, and one final StreamTaskMessageFull(ToolRequestContent) with parsed args.
  • Malformed args: emits arguments={} in the final Full and logs a WARNING.
• Full test_streaming_model.py suite passes (42/42).
• ruff check clean on both modified files.
• Manual smoke: deploy to a dev environment with an agent that calls a write-heavy tool, confirm UI sees tool args streaming in coalesced batches.
• Manual smoke: streaming_mode="off" suppresses tool-arg deltas (only the final persisted message exists on close).

cc reviewers familiar with #333's CoalescingBuffer design.

Greptile Summary

This PR threads tool-call argument deltas through the same CoalescingBuffer-backed streaming machinery already used for text and reasoning output. Each function call now opens its own streaming_task_message_context on ResponseOutputItemAddedEvent, emits a ToolRequestDelta per ResponseFunctionCallArgumentsDeltaEvent, and closes with a ToolRequestContent Full on ResponseOutputItemDoneEvent, eliminating the multi-second UI freeze caused by write-heavy tools buffering their entire argument body.

• Streaming lifecycle: context opened per call → delta emit per chunk → Full + close on Done; orphan cleanup defensively closes any context that didn't receive a Done event (truncated stream / mid-stream exception).
• Fault tolerance: JSONDecodeError on the final arg parse falls back to arguments={} and logs only the byte count, keeping sensitive content out of production logs; all stream_update / close calls are individually guarded so a streaming failure never breaks the main activity path.
• Tests: two new async tests cover the happy path (delta-per-chunk fidelity, parsed Final Full) and the malformed-JSON fallback (arguments={} + WARNING log), complementing the existing 42-test suite.

_{Reviews (5): Last reviewed commit: "Merge branch 'next' into vkalmath/stream..." | Re-trigger Greptile}