From 74627a69e6e2c8f7ddf047696e562c642134789a Mon Sep 17 00:00:00 2001 From: oaris-dev <76177243+oaris-dev@users.noreply.github.com> Date: Sun, 17 May 2026 13:33:02 +0200 Subject: [PATCH] fix(web): write PROCESSING status to DB before triggering transcription workflow Prevents the share page polling loop (`/s/` every 2s) from re-firing `start(transcribeVideoWorkflow, ...)` concurrently. Without this write, every poll passes the `!video.transcriptionStatus` check and queues another workflow dispatch. After a few concurrent enqueues, `@workflow/world-local`'s queue races on its internal buffers and detaches the underlying ArrayBuffer, crashing dispatch before any workflow step executes. By writing PROCESSING to the DB synchronously *after* the early-return check in `transcribeVideo` but *before* the `start()` call, the next poll's call to `transcribeVideo` hits the early-return and never re-fires `start()`. The first dispatch completes normally. Fixes #1550. Verified end-to-end by @julianwitzel on a self-hosted Docker deployment that was previously stuck in the ArrayBuffer crash loop. Co-Authored-By: Claude Opus 4.6 (1M context) --- apps/web/lib/transcribe.ts | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/apps/web/lib/transcribe.ts b/apps/web/lib/transcribe.ts index 606ef72f741..e3ea0c54c68 100644 --- a/apps/web/lib/transcribe.ts +++ b/apps/web/lib/transcribe.ts @@ -115,6 +115,11 @@ export async function transcribeVideo( `[transcribeVideo] Triggering transcription workflow for video ${videoId}`, ); + await db() + .update(videos) + .set({ transcriptionStatus: "PROCESSING" }) + .where(eq(videos.id, videoId)); + await start(transcribeVideoWorkflow, [ { videoId,