fix(google-meet): handle stdout/stderr stream errors in local audio bridge#101596
Conversation
|
Codex review: needs maintainer review before merge. Reviewed July 7, 2026, 9:04 PM ET / 01:04 UTC. Summary PR surface: Source +27, Tests +288. Total +315 across 3 files. Reproducibility: yes. at source level: current main attaches data listeners to child stdout/stderr streams in the Google Meet command-pair bridge without matching error listeners, and Node streams raise unhandled error events unless handled. I did not reproduce it in a live Meet call. Review metrics: none identified. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Merge the narrow plugin-owned stream-handler fix after exact-head CI and maintainer review, treating full live Meet audio-device validation as optional release smoke rather than a blocker for this stream-handling patch. Do we have a high-confidence way to reproduce the issue? Yes at source level: current main attaches data listeners to child stdout/stderr streams in the Google Meet command-pair bridge without matching error listeners, and Node streams raise unhandled error events unless handled. I did not reproduce it in a live Meet call. Is this the best way to solve the issue? Yes: the PR reuses the existing fail/stop path for primary bridge stream failures and logs optional barge-in stream errors instead of adding a parallel recovery path. A live audio-device E2E would add confidence but is not necessary to validate this stream-handler fix. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 81d0f3f37291. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +27, Tests +288. Total +315 across 3 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (1 earlier review cycle)
|
|
Maintainer validation is complete for exact head What I verified:
Proof gap: no live macOS SoX/CoreAudio/BlackHole Google Meet call was run. The changed Node stream contract is covered by the real spawned command-pair process test, so this is an optional environment smoke rather than a landing blocker. Ready for squash merge. |
|
Merged via squash.
|
…ridge (openclaw#101596) * fix(google-meet): handle stdout/stderr stream errors in local audio bridge * test(google-meet): prove command bridge stream errors
…ridge (openclaw#101596) * fix(google-meet): handle stdout/stderr stream errors in local audio bridge * test(google-meet): prove command bridge stream errors
Summary
errorhandlers for Google Meet command audio bridge child streamsstoppath is idempotent (stoppedguard), so duplicate stream errors cannot tear down twice or kill twicestartCommandAgentAudioBridgeextensions/google-meet/src/realtime.tsVerification
node scripts/run-vitest.mjs run --config test/vitest/vitest.extensions.config.ts extensions/google-meet/index.test.ts -t "stops the Chrome agent audio bridge|stops the Chrome realtime audio bridge|pipes Chrome command-pair audio through the realtime provider"— passed; 1 file, 3 tests passed, 100 skippednode scripts/run-vitest.mjs extensions/google-meet/src/realtime.process.test.ts -- --reporter=verbose— passed; 1 file, 1 test passed (real local child-process proof)node scripts/run-oxlint.mjs --tsconfig config/tsconfig/oxlint.extensions.json extensions/google-meet/src/realtime.process.test.ts— passedgit diff --check— passedEPIPE from real bridge input stdout; restoring the handler made it passReal behavior proof
Behavior addressed: Google Meet local command-pair audio bridge stdout stream errors are contained by the existing bridge fail/stop path, without an unhandled stream error or repeated teardown.
Real environment tested: local Linux Node source checkout; the proof wires two real local substitute command processes through
startCommandAgentAudioBridgewith real child pipes. It is not a live Google Meet call and not the default SoX/CoreAudio/BlackHole device chain.Exact steps or command run after this patch:
node scripts/run-vitest.mjs extensions/google-meet/src/realtime.process.test.ts -- --reporter=verbose.Evidence after fix:
[proof] local command-pair substitute stopped after forced input stdout stream error; inputPid=3847906 outputPid=3847905;Test Files 1 passed (1); Tests 1 passed (1).Observed result after fix: a forced stdout stream error on the real spawned input command logs through
audio input command stdout failed, bridge health reportsbridgeClosed=true, the STT session closes exactly once, and both input/output command processes emitcloseafter a single SIGTERM each.What was not tested: a live Google Meet/Chrome audio device run and the default macOS SoX/CoreAudio
BlackHole 2chcommands — this Linux environment has nosoxbinary and no CoreAudio/BlackHole device, so the closest honest local proof is a real substitute command pair driving the real exported bridge function.