Speech to text not working in production

[einari]

Doing speech to text in the generate dialogs doesn't seem to be working. Its showing that its kind of recording with the visualization of volume and recording.

[einari]

Ruled out the whole server side. Everything from Core inwards works, verified against production by port-forwarding straight to a Core pod and bypassing AuthProxy:

• GET /api/agent/transcription/available -> {"available":true}
• POST /api/agent/transcription/{sessionId} with a WAV -> HTTP 200 in 2.7s
• The same POST with webm/opus, which is what MediaRecorder actually produces -> HTTP 200 in 2.0s
• Subscribing to /api/transcriptions/transcription-for-session while posting audio streamed the recognized text back: {"id":"...","text":"You"} ("You" being whisper's usual answer for a pure tone)

The transcription service itself is healthy and has the model Core asks for (Systran/faster-whisper-tiny.en, matching StudioOptions.ModelName).

Also checked the cross-pod path, since Core runs two replicas and the audio POST and the SSE need not land on the same one. Orleans__Enabled=true, and the studio Orleans cluster has both Core pods Active with fresh heartbeats, so OrleansCrossPodStreamRelay is the registered relay rather than the local no-op.

The client logic reads correctly too: it submits the full recording on every ondataavailable while recording and again on stop, and sets the blob type from recorder.mimeType.

So the fault is in the last hop - through AuthProxy, or in the browser itself. These are plain minimal-API endpoints under /api/agent/... rather than Arc commands or queries, so they do not go through the same filters as the rest of the surface and are worth checking separately. AuthProxy's logs show nothing for these paths at all.

Two things worth checking next, both needing a real signed-in session:

1. What the browser's network tab reports for POST /api/agent/transcription/{id} - a status, or no request at all.
2. Whether recorder.mimeType is audio/mp4 rather than audio/webm. Safari's MediaRecorder produces mp4/aac; the client always names the upload audio.webm regardless of the real type, which would be worth correcting either way.