feat: add confirmToolCall support to CAS chat bridge [JAR-8666]

[JoshParkSJ]

What changed?

Tool confirmation is no longer modeled as an interrupt — it is now a first-class property of the tool call itself.

The old model

The old flow used a separate interrupt mechanism: when a tool needed user approval, the bridge emitted a startInterrupt event (carrying tool-call metadata), waited for a matching endInterrupt event keyed on an interrupt_id, then resumed the agent with the approval result. Tool confirmation was a passenger inside a general-purpose interrupt envelope.

The new model

startToolCall now carries requireConfirmation: true and inputSchema directly, so CAS sees immediately — at tool invocation time — that this call needs user approval. The user's decision comes back as a confirmToolCall event on the same tool call, with { approved, input }. No interrupt envelope, no ID matching, no parallel event streams.

This is a tighter fit: confirmation is a property of the tool call, so it lives on the tool call event.

What this means in practice

• Data models (uipath-core): interrupt.py deleted entirely. Confirmation state (requireConfirmation, inputSchema, confirmation) moves onto the tool call models. A new UiPathConversationToolCallConfirmationEvent carries the user's approve/reject decision.
• Bridge (_bridge.py): Drops the interrupt-ID-matching logic. Now just watches for confirmToolCall on incoming tool call events and sets the resume event. emit_interrupt_event() is kept as a documented no-op to satisfy the UiPathChatProtocol contract — it has no work to do in this flow.
• Cleanup: interrupts field removed from message models; interrupt field removed from UiPathConversationMessageEvent. All call sites updated.

Testing

Manual end-to-end with tc-1 agent: Accept, Cancel, Modify+Accept, and empty required field validation all verified working for low code and coded agents

Companion PRs

• AgentInterfaces#899 — CAS frontend: removes interrupt handler, adds confirmToolCall
• uipath-langchain-python#703 — emits startToolCall with requireConfirmation; handles confirmation discovery
• uipath-runtime-python#104 — removes emit_interrupt_event from protocol

[JoshParkSJ]

I still believe for conversational experience we won't ever need to support this type of generic interrupt. This type of interrupt("...") is really for workflow type / autonomous agent experience. But Pufu's suggestion was that there's no cost of keeping this runtime protocol here as a no-op and potential flexibility. So keeping it here. For CAS code though, removing interrupt simplifies our codebase significantly - so doing a rip-and-replace makes sense

[maxduu]

Thanks for the comment but can we just remove emit_interrupt_event and its references in all the other files?

[JoshParkSJ]

Yeah I wanted to delete it but Pufu wanted the runtime repo to be untouched in case we have to add it back in the future. He said just no-op it here