Guardrail follow-up can race with response.cancel completion

[felmonon]

After #1968 added force_response_cancel=True, the guardrail interrupt itself works, but there's still a gap between the cancel and the follow-up.

In _run_output_guardrails (session.py L956-964), after sending RealtimeModelSendInterrupt(force_response_cancel=True), the code immediately sends RealtimeModelSendUserInput with the guardrail message. That user input ends up calling response.create through openai_realtime.py L472-475. If the server hasn't finished processing the cancel yet (i.e. response.done hasn't come back), you get:

Conversation already has an active response in progress: resp_...

I ran into this while testing with turn_detection.interrupt_response enabled on a setup with some network latency. Same error that #1907 originally reported — a commenter on #1912 (2025-10-23) also hit it after upgrading to 0.4.1.

What's happening

_run_output_guardrails
  → send_event(RealtimeModelSendInterrupt(force_response_cancel=True))  # sends response.cancel
  → send_event(RealtimeModelSendUserInput(...))                         # sends response.create
     ^ nothing waits for response.done in between

Debug information

• Agents SDK version: 0.13.0
• Python version: 3.12

Expected behavior

Wait for response.done for the interrupted response before sending the follow-up input.

[seratch]

Thanks for reporting this issue. This is a valid feedback and we'll resolve it in the next release.

[felmonon]

Thanks for confirming and for the quick turnaround. The response.cancel / follow-up response.create gap was the failure mode I hit, so #2763 looks right. I’ll re-test once the 0.13.x release is out.