fix(vapi): subscribe to end-of-call-report so SMS dispatch can fire

[ByteStreams-AI]

Summary

Live SQL diagnosis surfaced the actual root cause behind every "didn't get the SMS" report in this session: voice_calls rows from real calls had ended_at=NULL and ended_reason=NULL. vapi_call_end never fired on any call. The entire post-call SMS dispatch path was dead code from the moment we moved to dynamic assistant config.

Root cause: Vapi assistants only deliver webhook events for message types declared in serverMessages. Static dashboard-defined assistants come with a default checklist; dynamic assistants returned via assistant-request inherit only what the response declares. Our response set endCallFunctionEnabled, voice, transcriber, model, tools — but never serverMessages. Vapi happily delivered tool-calls (because tools have explicit server.url configs) but end-of-call-report was silently filtered out.

That explains every previous failure mode in this branch:

• "Call doesn't hang up" → was actually a separate issue, but...
• "SMS didn't arrive" → because vapi_call_end never ran.
• PR fix(voice): cart integrity + clean termination + SMS dispatch resilience #27's three-gate dispatch logic → couldn't help, because the function it gates was never invoked.

Fix: declare the subscription list explicitly:

serverMessages: ['tool-calls', 'end-of-call-report', 'status-update', 'hang']

Integration test updated to assert serverMessages includes end-of-call-report and tool-calls, plus endCallFunctionEnabled === true.

Test plan

• pnpm ci:fast — 299/299
• After deploy: place a test call, complete the order flow, then verify with:

  select vapi_call_id, ended_at, ended_reason, order_id
  from voice_calls
  order by started_at desc limit 1;

  ended_at should be set, ended_reason populated.
• Confirm the SMS payment link arrives.
• Confirm sms_messages row exists with twilio_status='sent'.

🤖 Generated with Claude Code

Greptile Summary

Fixes a silent post-call SMS dispatch failure caused by Vapi not delivering end-of-call-report webhooks to dynamically-configured assistants that never declared serverMessages. The fix adds an explicit serverMessages subscription list (tool-calls, end-of-call-report, status-update, hang) to the handleAssistantRequest response; all four types are already handled in the existing routing switch. The integration test is updated to assert the two critical entries and endCallFunctionEnabled.

Confidence Score: 5/5

Safe to merge — targeted one-field addition with a matching regression test and no side-effects on existing handlers.

The change is minimal and directly corrects a well-diagnosed root cause. The four serverMessages values exactly match the message types already handled in the routing switch, so no dead subscriptions are introduced. Test coverage for the critical field is now in place.

No files require special attention.

Important Files Changed

Filename	Overview
supabase/functions/vapi_call_start/index.ts	Adds serverMessages subscription list to the dynamic assistant response so Vapi delivers end-of-call-report webhooks; all four declared message types are already handled in the routing switch.
packages/shared/test/db/voice.test.ts	Extends the assistant-request response type and adds assertions for serverMessages containing both end-of-call-report and tool-calls, and for endCallFunctionEnabled === true.

_{Reviews (1): Last reviewed commit: "fix(vapi): subscribe to end-of-call-repo..." | Re-trigger Greptile}