fix(vapi): bisect 'Couldn't get assistant' — strip recent assistant config additions

[ByteStreams-AI]

Symptom

Calls hit "Couldn't get assistant" from Vapi. Reproduced May 5 2026 multiple times.

What we know

• Telnyx → Vapi handoff is fine. SIP flow on Telnyx's Debugging panel shows a complete INVITE → 100 → 180 → 200 → ACK → BYE in 8 seconds. Vapi answers the call briefly to play its error audio, then drops.
• Our Edge Function returns 200 to Vapi successfully. Supabase Edge Function logs show 4 invocations of `vapi_call_start` at 21:38:07 and 21:40:06 on May 4, all returning 200 in ~270ms. So our function isn't erroring.
• The rejection happens inside Vapi's runtime validator after parsing our response. Something in the assistant config we return is now rejected, even though identical config worked in PR fix(voice): cart integrity + clean termination + SMS dispatch resilience #27.
• PRs fix(vapi): subscribe to end-of-call-report so SMS dispatch can fire #28-fix(vapi): drop serverMessages — phone-number-level subscription #30 chain is fully reverted — current `main` is functionally identical to PR fix(voice): cart integrity + clean termination + SMS dispatch resilience #27 (only a comment-block diff).

Root cause hypothesis

Vapi tightened validation on one of these fields between May 4 (PR #27 deploy worked) and May 5 (post-PR #30 deploy fails):

• `endCallFunctionEnabled: true`
• `endCallPhrases: [...]`
• per-tool `messages` array — `request-response-delayed` filler ("Just a second.")
• per-tool `messages` array on `end_call` — `request-complete` with `endCallAfterSpoken: true`

Proposed approach

Bisect by stripping all four to a known-good baseline. If the call connects, add fields back one at a time (separate Issues per restoration) to identify which one broke.

File to edit

`supabase/functions/vapi_call_start/index.ts` — `handleAssistantRequest` function.

Specific edits

1. Strip from the assistant response object:

• Remove `endCallFunctionEnabled: true`
• Remove `endCallPhrases`

2. Strip the `endCallPhrases` array declaration above (the 15-phrase list with comment).

3. Strip per-tool `messages` from `wrappedTools`:

• Remove the special `if (t.name === 'end_call')` branch with `request-complete` + `endCallAfterSpoken: true`
• Remove `messages: toolDelayMessages` from the default branch
• Strip the `toolDelayMessages` declaration above

After stripping, each wrapped tool should be just:
```ts
{
type: 'function' as const,
function: { name: t.name, description: t.description, parameters: t.parameters },
server: { url: dispatcherUrl, timeoutSeconds: 20 },
}
```

4. Update integration tests in packages/shared/test/db/voice.test.ts:

• Remove `expect(json.assistant.endCallFunctionEnabled).toBe(true)` if present
• Remove `expect(json.assistant.serverMessages).toBeUndefined()` if it's still there from PR fix(vapi): drop serverMessages — phone-number-level subscription #30 (still fine but no longer required)

Expected diff scope

• One file: `vapi_call_start/index.ts` — ~50 line removal
• Maybe one test file: `voice.test.ts` — 1-2 assertion removals
• 299/299 unit tests should still pass

Test plan

• `pnpm ci:fast` green
• Deploy to cloud
• Place a test call to +16296001047
• If the call connects: breaking field is one of the four. File restoration Issues for each, individually.
• If still fails: look further upstream — possibly model name (`gpt-4o-mini`), prompt size, or tool wrap shape.

Risk + UX regression if this lands

• Slow tool calls produce silence instead of "Just a second" filler
• Calls may not auto-hang-up after goodbye if the LLM forgets `end_call`
• All recoverable by re-adding the offending field with caution

What is NOT touched

• All prompt logic (cart verification, customer name, phone confirm, modifier discipline, agent_name)
• All Edge Functions (`vapi_get_cart_state`, `vapi_cancel_order`)
• All tool schemas (`get_cart_state`, `cancel_order`)
• All cart integrity work, three-gate SMS dispatch
• Vapi/Telnyx/Stripe/Supabase external configurations

Suggested branch + commits

```
git checkout -b fix/m11-strip-assistant-config-bisect

edits per "Specific edits" above

pnpm ci:fast
git diff # review
git commit -am "fix(vapi): bisect — strip endCall* and per-tool messages from assistant config"
git push -u origin fix/m11-strip-assistant-config-bisect
gh pr create --title "fix(vapi): strip recent assistant config additions to isolate Vapi validator regression"
```

Rollback

If the strip breaks something else: `git revert` and we're back to current main. The strip touches only one file's response shape, no schema or external config.

[ByteStreams-AI]

Round 1 strip (endCallFunctionEnabled, endCallPhrases, per-tool messages) deployed in PR #41 didn't unblock 'Couldn't get assistant'. Reopening for round 2: strip legacy functions field. See PR #N for the next attempt.

[ByteStreams-AI]

Round 1 result — May 5, 2026

Failed. PR #41 deployed to staging, called +1 629 250 3998, still hit "Couldn't get assistant".

The four fields stripped in round 1 are NOT the breaking field:

• ❌ endCallFunctionEnabled: true
• ❌ endCallPhrases: [...]
• ❌ per-tool messages arrays (request-response-delayed filler)
• ❌ per-tool messages arrays on end_call (request-complete with endCallAfterSpoken: true)

Voice ID also ruled out (separate hypothesis): update restaurants set voice_id = null on staging didn't help either.

Round 2 — strip legacy functions: tools fallback

Branch: fix/vapi-bisect-strip-functions-fallback (ready for review and PR).

The model config currently supplies BOTH:

• tools: wrappedTools — the OpenAI tools API envelope ({type, function: {name,description,parameters}, server})
• functions: tools — the legacy flat shape ({name, description, parameters})

Hypothesis: Vapi tightened validation and now rejects assistant configs that supply both on the same model object. The legacy functions field was added back when Vapi only understood the flat shape; it's been redundant since the OpenAI tools API became standard.

Diff: one line removed in supabase/functions/vapi_call_start/index.ts. 299/299 unit tests pass.

Round 3+ candidates if round 2 also fails

In order of suspicion:

1. Tool wrapper shape — try removing server from individual tools, use a single top-level dispatcher URL
2. Prompt size — system prompt is ~270 lines; truncate to a stub to test length
3. Model name — try gpt-4o instead of gpt-4o-mini (Vapi may have deprecated mini)
4. Transcriber config — try omitting (Vapi may default)

[ByteStreams-AI]

Full restore confirmed: PR #47 merged to main. Root cause was staging DB phone number mismatch (+16296001047 vs staging Telnyx number +16292503998) — bisect correctly ruled out assistant config shape. Phone normalization hardened in PR #46. Integration test re-enabled and asserting endCallFunctionEnabled + endCallPhrases. Ready for staging smoke test before prod promotion.