Vexa-ai/vexa

The job you're trying to get done Currently audio is recorded, video is not. I would like to add the capability to record video for meetings. Video recording will support multiple codecs and encoders. I will also be fixing issues with the browser not starting in fullscreen; we want to make sure no real estate is wasted in the recording. How you work around it today I don't, I need this capability so am building it. I built it for an old version ~6 months ago but need to rebuild for 0.12.

Gap (adjacent to #843/#855, not covered by it) The #855 intake validation guards native_meeting_id against length (>255) and NUL/control bytes → typed 422. But a value carrying URL-reserved characters (e.g. a Teams passcode accidentally left on the id: 397421056486982?p=X8hcQVTnGNpGelJLSv) passes both guards (short, no control bytes) and is accepted. Then three things break downstream, none typed: Malformed join URL. construct_meeting_url string-interpolates the raw id into the template (teams: https://teams.microsoft.com/l/meetup-join/{native_meeting_id}), yielding …/l/meetup-join/397421056486982?p=X8hcQVTnGNpGelJLSv — the bot fails to join (join_failure). Unfindable record. platform_specific_id is stored as the full 397421056486982?p=… string, so the dashboard (which looks up by the clean numeric id 397421056486982) returns 'Meeting not found for platform teams and ID 397421056486982'. The user sees a bot that 'fails to join' with no indication that the input was malformed.

Value this issue delivers A first-time contributor on macOS/Docker Desktop reaches a working edit-live hot stack (terminal + backend, change visible in seconds) by following one written page, without reverse-engineering Makefiles or hitting undocumented first-run failures. Why this matters The hot loop is how user-experience-driven fixes actually get made — see, edit, see again. Today the correct invocation exists nowhere in tracked docs: grep -r "docker-compose.hot" **/*.md **/*.mdx returns zero hits. A contributor who follows the only written instructions (the overlay's own header comments) creates a second, broken parallel stack. Every new contributor re-pays the same discovery cost; some just leave. Where we are (honest) Observed on a fresh main pull (582d1ed), macOS (Apple Silicon), Docker Desktop, 2026-07-17: The working loop is: make dev (project vexa-v012, IMAGE_TAG=dev), then layer the hot overlay: IMAGE_TAG=dev docker compose -p vexa-v012 -f docker-compose.yml -f docker-

Why this matters The meeting tab's header renders a bot-control button — Live badge + "Stop bot" — whose label and click-signal are derived from the last snapshot the store happened to hold, not from the live WebSocket that is supposed to be the authoritative state channel. When the live meeting.status stream is not attached, the store simply keeps its last-known snapshot, and the header keeps rendering Live + "Stop bot" for a meeting the backend no longer has. The user then clicks a control whose label contradicts reality and fires the wrong signal. This was witnessed live today on the v0.12.7 helm deployment. A meeting tab showed the LIVE badge and an actionable "Stop bot" while the backend held no active meeting for that native id — the session had gone stale across a terminal redeploy. Clicking "Stop bot" issued DELETE /api/bots/{platform}/{native}, which returned 404, and the UI surfaced the raw upstream string as a toast overlapping the header: ⚠ 404 Not Found: {"detail":

Why this matters Live-witnessed on a fresh v0.12.1 lite deploy (2026-07-12): the bot's transcription failed and the Terminal displayed "Stream error: Meeting stream disconnected; reconnecting" with a perpetual "Waiting for transcript…". The actual fault, which the bot logged precisely, was upstream and unrelated to the stream transport: [TranscriptionClient] stt unavailable (HTTP 503): {"detail":"Remote transcription fallback saturated: concurrency"} [bot] pipeline fault: TranscriptionError: stt unavailable (HTTP 503) The system HAS the truth (bot pipeline fault: STT backend rejecting) and the UI renders a fiction about a different layer (the WS stream). A user follows the UI and debugs their network/connection; the real problem is the transcription service. The error surface points at the wrong layer. This is the live confirmation of the class #533 raised. Value this issue delivers When transcription fails, the Terminal names the actual fault ("transcription backend unavailable