Context
Observed during v0.10.6.1 develop-sign UAT while dispatching a Zoom Web bot. This is not the same failure mode as #318.
Symptom
The Zoom bot reached meeting_status: active after a brief needs_human_help pass-through, but produced 0 transcripts. Container logs show the bot attempted to join audio three times, then escalated because it could not confirm audio join. Downstream browser audio capture then started with 0 streams.
Relevant log excerpt:
20:12:55 Audio button aria-label: "join audio" (attempt 1)
20:12:57 Clicked Join Audio footer button — waiting for dialog...
20:12:58 Audio button aria-label: "join audio" (attempt 2)
20:12:58 Clicked Join Audio footer button — waiting for dialog...
20:13:30 Audio button aria-label: "audio" (attempt 3)
20:13:30 Clicked Join Audio footer button — waiting for dialog...
20:13:31 FAIL: audio_join_failed — could not confirm audio join after 3 attempts. Escalating to needs_human_help so dashboard surfaces VNC link.
20:13:34 Audio verification: 0 elements with audio streams (2 total media elements)
20:13:36 Deep diagnostic: canvasExists=true canvasStreamExists=true gumCallCount=2 peerConnections=16 injectedAudioElements=0
20:13:56 Browser-side audio capture started with 0 streams
Why this is distinct from #318
#318 describes the downstream Zoom Web per-speaker pipeline after audio has successfully joined: Zoom no longer exposes <audio>.srcObject DOM elements, so the bot sees 0 streams even though speaker events fire.
This issue happens earlier. The bot could not confirm that it had joined computer audio. Attempt 3 saw the toolbar aria-label change from join audio to audio, which suggests the click may have flipped Zoom into a joined state, but the confirmation logic was looking for the wrong signal or missed the state transition.
Expected behavior
For Zoom Web meetings, after clicking Join Audio / Join with Computer Audio, the bot should detect joined audio state reliably and proceed without raising needs_human_help when the toolbar has actually entered the joined-audio state.
Acceptance sketch
- Add a Zoom Web regression prove where the post-click toolbar state changes to an audio/joined label without the old dialog confirmation path.
- Bot treats the confirmed joined toolbar state as success.
audio_join_failed only fires when both the dialog path and toolbar joined-state checks fail.- A real Zoom Web bot with an admitted participant produces non-empty audio/transcript evidence or fails with a more specific diagnostic.
Release disposition
For v0.10.6.1: track this as a pre-existing Zoom Web reliability bug and accept-with-rationale in develop-sign. The long-term Zoom Meeting SDK path (#253) may supersede the Web confirmation path, but the Web path needs a ticket until then.
Context
Observed during v0.10.6.1 develop-sign UAT while dispatching a Zoom Web bot. This is not the same failure mode as #318.
Symptom
The Zoom bot reached
meeting_status: activeafter a briefneeds_human_helppass-through, but produced 0 transcripts. Container logs show the bot attempted to join audio three times, then escalated because it could not confirm audio join. Downstream browser audio capture then started with 0 streams.Relevant log excerpt:
Why this is distinct from #318
#318 describes the downstream Zoom Web per-speaker pipeline after audio has successfully joined: Zoom no longer exposes
<audio>.srcObjectDOM elements, so the bot sees 0 streams even though speaker events fire.This issue happens earlier. The bot could not confirm that it had joined computer audio. Attempt 3 saw the toolbar aria-label change from
join audiotoaudio, which suggests the click may have flipped Zoom into a joined state, but the confirmation logic was looking for the wrong signal or missed the state transition.Expected behavior
For Zoom Web meetings, after clicking Join Audio / Join with Computer Audio, the bot should detect joined audio state reliably and proceed without raising
needs_human_helpwhen the toolbar has actually entered the joined-audio state.Acceptance sketch
audio_join_failedonly fires when both the dialog path and toolbar joined-state checks fail.Release disposition
For v0.10.6.1: track this as a pre-existing Zoom Web reliability bug and accept-with-rationale in develop-sign. The long-term Zoom Meeting SDK path (#253) may supersede the Web confirmation path, but the Web path needs a ticket until then.