[zachm-vapi]

Summary

Adds a videoRecordingStartMode option to vapi.start() so callers can choose who starts the video recording when artifactPlan.videoRecordingEnabled is on:

• client (the server's default): the Daily meeting token starts the cloud recording from the client when the user joins. This is today's behavior.
• server: Vapi starts the recording from its servers once the user has joined, so a weak client connection can't stop it from starting.

vapi.start(assistantId, undefined, undefined, undefined, undefined, {
  videoRecordingStartMode: 'server',
});

Tracks VAPICS-1747.

Changes

• New StartCallOptions.videoRecordingStartMode ('client' | 'server'), sent in the create-web-call body. When it isn't set it stays undefined, so older backends use the old client behavior instead of returning 400.

• Reads transport.videoRecordingStartMode from the web call in both start() and reconnect(). In server mode the video-recording-setup progress event reports action: 'started-by-server' instead of 'auto-started-via-meeting-token'.

• Server-side start failures are reported as recording-error. A video-recording.start-failed Daily app message is turned into a recording-error event (Vapi couldn't start the recording (<outcome>): <error>) so clients can continue to watch the existing event.

• The SDK no longer starts recordings itself. ⚠️ Before this change, if recording was enabled but the server sent no callToken, the SDK called startRecording() from the client. Now it starts nothing:

  • video-recording-setup reports status: 'failed' with action: 'no-meeting-token'.
  • A recording-error is emitted after start()/reconnect() resolves. It fires in a later task, so listeners added right after the await still get it, and it is skipped if the call was stopped or replaced in the meantime.
  • The error event with type: 'video-recording-setup-error' is no longer emitted.
  • Callers can still call startRecording() themselves if desired.

  In practice, the manual start is equivalent to the token start since they are both initiated by the client immediately after joining. The token has always been present in production, so the manual start provides no value.

• README: the Recording section now explains the two modes.

• Example app: adds a "Recording Start Mode" selector (default / client / server), logs recording-started and recording-error, and shows the call-start-progress action.

Before merging (why this is a draft)

There are two TODO(VAPICS-1747) comments in vapi.ts to resolve once the backend change is deployed and api.ts is regenerated from the prod spec:

• Replace the local VideoRecordingStartMode type alias with CreateWebCallDTO['videoRecordingStartMode']
• Remove the CreateWebCallDTO & { videoRecordingStartMode?: ... } intersection on createWebCallBody and use plain CreateWebCallDTO

[mhar-vapi]

looks good to me overall. please address the p2 timing gap below so a recording failure during join reaches the caller. ci is green, including all 86 tests and the sdk and example builds. the backend rollout and generated-type cleanup listed in the draft still need to happen before release.

[mhar-vapi]

[p2] please register the app-message listener before awaiting join in start(), as reconnect() already does. the server starts recording when it sees the user join, so its failure message can arrive while a slow client is still joining. start() currently attaches the listener afterward, dropping that message and never emitting recording-error. i reproduced this by delivering the failure during join: start() missed it, while reconnect() received it. please add that timing case to the tests.