[Bug] Video processing fails with "ArrayBuffer.prototype.slice on a detached ArrayBuffer" on self-hosted Docker

[eumatheusmoura]

Description

Video uploads complete successfully (multipart upload to MinIO works), but processing always fails with a TypeError: fetch failed caused by ArrayBuffer.prototype.slice on a detached ArrayBuffer.

The media-server never receives any processing request — only health checks. The error occurs inside cap-web when it tries to send the video to the media-server.

Error

[local world] Queue operation failed: TypeError: fetch failed
at async (.next/server/chunks/385.js:30:10424) {
[cause]: TypeError: Cannot perform ArrayBuffer.prototype.slice on a detached ArrayBuffer
at ArrayBuffer.slice ()
}

Environment

• Image: ghcr.io/capsoftware/cap-web:latest (v0.3.1, built 2026-02-16)
• Node.js in image: v24.13.1
• Host OS: Ubuntu, kernel 6.8.0-90-generic
• RAM: 8GB + 4GB swap
• Platform: Easypanel (Docker Compose)
• Storage: MinIO (self-hosted, working correctly)
• Media server: ghcr.io/capsoftware/cap-media-server:latest (healthy, FFmpeg 6.1.2)

What I tried (none resolved it)

1. Custom image with Node.js 22 (v22.22.1) — same error
2. UV_USE_IO_URING=0 — no effect
3. UNDICI_NO_FETCH=1 — no effect
4. NODE_OPTIONS="--max-old-space-size=4096" — no effect
5. security_opt: seccomp:unconfined — no effect
6. Added 4GB swap — no effect

Working on Railway

The same app deployed via the Railway template (https://railway.com/deploy/PwpGcf) works perfectly — video uploads and processing complete without issues.

Connectivity confirmed

• docker exec cap-web wget -qO- http://media-server:3456/health → {"status":"ok","ffmpeg":{"available":true,"version":"6.1.2"}}
• docker exec cap-web wget -qO /dev/null http://minio:9000/cap/ → OK

Conclusion

The bug appears to be in the compiled Next.js bundle (.next/server/chunks/385.js) which uses an embedded fetch implementation (undici). The ArrayBuffer gets detached during the fetch to the media-server, regardless of Node.js version or system configuration.

[linear]

CAP-654

[tembo]

This is a known issue affecting self-hosted Docker deployments. The root cause is in the workflow package (4.0.1-beta.42) used by Cap's video processing pipeline - its [local world] execution mode has an incompatibility that causes ArrayBuffer.prototype.slice on a detached ArrayBuffer errors when running inside Docker containers.

Related Issues:

• [Bug] Video processing fails with "detached ArrayBuffer" error #1539 - Original report of this bug (video processing)
• Transcription workflow fails on Docker image with Node 24 #1550 - Same error affecting transcription workflows

Key Context:
The error occurs in apps/web/workflows/process-video.ts when it uses the workflow package's "use workflow" / "use step" directives. The workflow code itself is correct - it just calls fetch() to POST JSON to the media-server (line 162-174). The ArrayBuffer detachment happens internally within the workflow package's local execution mode, not in Cap's code.

Cap Cloud works because it uses a distributed workflow runner via WORKFLOWS_RPC_URL which doesn't have this issue. Self-hosted deployments use the problematic [local world] mode.

Existing PR:
PR #1630 has been open since February 24 with a fix that bypasses the broken workflow package entirely by replacing the async workflow calls with direct synchronous implementations for transcription and AI generation. It's been tested successfully on a staging instance.

Temporary Workarounds (until PR #1630 or similar fix is merged):

1. Deploy using the Railway template (as you noted works), or
2. Build a custom image using the branch from PR fix: bypass broken workflow package for self-hosted transcription and AI generation #1630: oaris-dev:fix/self-hosted-transcription

The Dockerfile at apps/web/Dockerfile:3 currently uses node:24-alpine, but as confirmed in #1550 comments, downgrading to Node 20 or 22 does not resolve this issue - it's an architectural problem with how the workflow package handles local execution in containerized environments.