Is your feature request related to a problem? Please describe.
RealtimeTarget.receive_events_async in pyrit/prompt_target/openai/openai_realtime_target.py has accumulated a large, deeply nested event-processing state machine. It currently spans roughly 127 lines with nine levels of nesting and more than 20 branches while handling audio, transcripts, stale events, errors, cancellation, soft completion, barge-in, and terminal conditions.
This makes timing and lifecycle behavior difficult to reason about. The method is used by both realtime send paths, and recent fixes around event routing, WAV reads, and completion grace periods show that this is a change-sensitive reliability boundary. Size alone is not the concern: the issue is that event classification, per-turn state mutation, and deadline management are interleaved.
Describe the solution you'd like
Refactor the receive loop around an explicit typed per-turn state object and a small event-step function. The outer method should retain ownership of the receive lifecycle, while the extracted logic should make these transitions explicit:
- accepted versus stale events;
- audio and transcript accumulation;
- soft-finish versus terminal completion;
- server errors and disconnects;
- cancellation and cleanup;
- barge-in behavior;
- one fixed completion deadline rather than a deadline that can be reset by unrelated late events.
Preserve public behavior and transport semantics. This should be a behavior-preserving refactor unless a separately documented test exposes a real defect.
Describe alternatives you've considered, if relevant
Splitting the method into several pass-through helpers without introducing an explicit state model would reduce line count but not reduce complexity. Moving event decisions into the target transport would also blur component responsibilities: the target should manage transport state, but attack decisions remain outside it.
Additional context
Suggested validation:
- existing direct realtime target tests;
- streaming-session and both send paths;
- stale-event and late-event sequences;
- disconnect/reconnect and server-error handling;
- cancellation and teardown;
- soft completion, barge-in, and fixed-deadline behavior;
- exact event ordering and no duplicate terminal results.
This is high-value but high-risk streaming work. A focused design and incremental tests are preferable to a broad rewrite.
Is your feature request related to a problem? Please describe.
RealtimeTarget.receive_events_asyncinpyrit/prompt_target/openai/openai_realtime_target.pyhas accumulated a large, deeply nested event-processing state machine. It currently spans roughly 127 lines with nine levels of nesting and more than 20 branches while handling audio, transcripts, stale events, errors, cancellation, soft completion, barge-in, and terminal conditions.This makes timing and lifecycle behavior difficult to reason about. The method is used by both realtime send paths, and recent fixes around event routing, WAV reads, and completion grace periods show that this is a change-sensitive reliability boundary. Size alone is not the concern: the issue is that event classification, per-turn state mutation, and deadline management are interleaved.
Describe the solution you'd like
Refactor the receive loop around an explicit typed per-turn state object and a small event-step function. The outer method should retain ownership of the receive lifecycle, while the extracted logic should make these transitions explicit:
Preserve public behavior and transport semantics. This should be a behavior-preserving refactor unless a separately documented test exposes a real defect.
Describe alternatives you've considered, if relevant
Splitting the method into several pass-through helpers without introducing an explicit state model would reduce line count but not reduce complexity. Moving event decisions into the target transport would also blur component responsibilities: the target should manage transport state, but attack decisions remain outside it.
Additional context
Suggested validation:
This is high-value but high-risk streaming work. A focused design and incremental tests are preferable to a broad rewrite.