fix(voice-call): play inbound greeting for Twilio answered calls#29121
fix(voice-call): play inbound greeting for Twilio answered calls#29121steipete merged 3 commits intoopenclaw:mainfrom
Conversation
Greptile SummaryRemoves Twilio-specific early-return in Key changes:
Testing:
Confidence Score: 5/5
Last reviewed commit: 39f45e3 |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 39f45e38f2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return; | ||
| } | ||
|
|
||
| void this.speakInitialMessage(call.providerCallId); |
There was a problem hiding this comment.
Reintroduce Twilio skip for answered-message playback
Calling speakInitialMessage unconditionally on call.answered now affects Twilio notify calls, but Twilio notify mode already injects a one-shot <Say><Hangup/> TwiML in initiateCall. This means answered callbacks can trigger a second playTts update that overwrites the notify flow (potentially replacing immediate hangup with <Gather>) or fails after the call has already ended, and either way initialMessage gets cleared so it cannot be retried on stream connect. This regression is specific to Twilio answered events and changes notify-call behavior from single-play/auto-end to duplicate or inconsistent playback.
Useful? React with 👍 / 👎.
39f45e3 to
71a1138
Compare
|
@chatgpt-codex-connector Good catch on Twilio notify-mode behavior. I rebased this PR and will validate answered-event playback against the existing Twilio Say+Hangup flow to avoid duplicate/overwriting playback. If conflict is confirmed, I will restore the Twilio guard (or narrow the condition) and update tests accordingly. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 71a11386cd
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return; | ||
| } | ||
|
|
||
| void this.speakInitialMessage(call.providerCallId); |
There was a problem hiding this comment.
Restore Twilio notify guard on answered callbacks
For Twilio outbound calls in notify mode, initiateCall already provisions a one-shot <Say>...<Hangup/> TwiML, but this answered-path now always triggers speakInitialMessage again. That second path calls playTts (which updates the live call to TwiML with <Gather>) and clears metadata.initialMessage before success is confirmed, so answered status callbacks can overwrite the notify flow, cause duplicate playback, or drop the message if the call already ended.
Useful? React with 👍 / 👎.
|
Validation update: I re-ran after rebase and it passes (12/12), including the Twilio/Plivo initial-notify greeting path. Current remaining red CI is the known Windows Feishu proxy test, unrelated to this voice-call change. |
|
Clean follow-up: validated after rebase; voice-call manager test suite passes (12/12), including Twilio/Plivo initial-notify greeting behavior. Remaining red CI is the known Windows Feishu proxy test and appears unrelated to this voice-call change. |
41d6cdf to
a9cfed5
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a9cfed53b5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return; | ||
| } | ||
|
|
||
| void this.speakInitialMessage(call.providerCallId); |
There was a problem hiding this comment.
Skip Twilio notify replay on answered callbacks
Fresh evidence in this revision: Twilio notify calls still deliver a one-shot <Say><Hangup/> via stored TwiML and separate status callbacks (extensions/voice-call/src/providers/twilio.ts), but this new unconditional call to speakInitialMessage on call.answered makes those status callbacks invoke playTts again for notify mode. That can replace the notify hangup flow with <Gather>/second playback (or fail if the call already ended), and speakInitialMessage clears metadata.initialMessage before confirming playback, so the greeting is lost on failure (extensions/voice-call/src/manager/outbound.ts).
Useful? React with 👍 / 👎.
a9cfed5 to
9b87505
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9b87505993
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return; | ||
| } | ||
|
|
||
| void this.speakInitialMessage(call.providerCallId); |
There was a problem hiding this comment.
Keep Twilio notify calls out of answered greeting replay
For Twilio outbound notify calls, the provider already serves one-shot notify TwiML (<Say>...<Hangup/>) from initiateCall, so replaying speakInitialMessage on every call.answered introduces a second playback path that can overwrite the notify flow with playTts call updates (or fail after hangup). In this path speakInitialMessage clears metadata.initialMessage before confirming playback, so a failed replay also drops the greeting entirely; this regression is introduced by removing the Twilio skip and affects answered status-callback handling for Twilio notify mode.
Useful? React with 👍 / 👎.
9b87505 to
b8f32ce
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b8f32cea65
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return; | ||
| } | ||
|
|
||
| void this.speakInitialMessage(call.providerCallId); |
There was a problem hiding this comment.
Skip manager TTS for Twilio notify answered events
maybeSpeakInitialMessageOnAnswered now unconditionally calls speakInitialMessage for Twilio, but outbound Twilio notify calls already deliver metadata.initialMessage through provider-side notify TwiML (generateNotifyTwiml served from TwilioProvider.initiateCall/generateTwimlResponse). Because Twilio status callbacks explicitly include answered, this path now runs on every notify call and can replay the greeting (or override the original <Hangup/> flow with a second TTS update), which changes call behavior and duration for existing Twilio notify users.
Useful? React with 👍 / 👎.
Summary
CallManager.maybeSpeakInitialMessageOnAnsweredWhy
Inbound Twilio calls were creating
metadata.initialMessagebut never speaking it, because answered-call handling explicitly skipped Twilio.Fixes #29101
Testing
pnpm -C openclaw-repo test extensions/voice-call/src/manager.test.ts