Skip to content

fix: AbortSignal now sends CANCEL to stop running exec (#719)#938

Open
JacobiusMakes wants to merge 1 commit intoffmpegwasm:mainfrom
JacobiusMakes:fix/abort-signal-cancels-exec
Open

fix: AbortSignal now sends CANCEL to stop running exec (#719)#938
JacobiusMakes wants to merge 1 commit intoffmpegwasm:mainfrom
JacobiusMakes:fix/abort-signal-cancels-exec

Conversation

@JacobiusMakes
Copy link
Copy Markdown

Summary

Fixes #719. When AbortSignal fires during exec() or ffprobe(), a CANCEL message is now sent to the worker to actually stop the running FFmpeg command — not just reject the JS Promise.

Problem

Previously, aborting an exec() or ffprobe() only rejected the JavaScript Promise. The underlying WASM process continued running to completion, wasting CPU and making AbortController useless for long transcoding operations.

Fix

const.ts — Add FFMessageType.CANCEL to the message enum.

classes.ts — When the abort signal fires for EXEC or FFPROBE, send a CANCEL message to the worker (in addition to rejecting the Promise). Also fixes a memory leak: Blob URLs created for coreData/wasmData/workerData are now tracked in #blobURLs and revoked in terminate().

worker.ts — Handle CANCEL by calling ffmpeg.setTimeout(1), which sets the WASM-side watchdog to fire after 1ms. This is the same mechanism used by the existing timeout parameter — it stops the current command and returns exit code 1.

Known limitation

In single-thread mode, exec() blocks the worker's JS event loop while running WASM. The CANCEL message queues behind it and only executes after the command finishes. For true mid-execution cancellation, the multi-thread build (which uses SharedArrayBuffer) would be needed. This PR still improves the situation by:

  1. Rejecting the Promise immediately (existing behavior, preserved)
  2. Sending CANCEL so the next queued operation doesn't run
  3. Fixing the blob URL memory leak

Test plan

  • Abort an exec() before it starts — CANCEL arrives first, sets timeout to 1ms, exec returns immediately
  • Abort during a long transcode — Promise rejects, CANCEL queues
  • Call terminate() after using coreData/wasmData — verify no blob URL leak via DevTools memory panel
  • Existing test suite passes

🤖 Generated with Claude Code

@netlify
Copy link
Copy Markdown

netlify bot commented Mar 27, 2026

Deploy Preview for ffmpegwasm canceled.

Name Link
🔨 Latest commit 50f33d3
🔍 Latest deploy log https://app.netlify.com/projects/ffmpegwasm/deploys/69c6159b91e1c7000899421e

…sm#719)

Previously, aborting an exec() or ffprobe() only rejected the JS
Promise — the underlying WASM process kept running to completion.

Fix: when the abort signal fires for EXEC or FFPROBE, immediately
send a CANCEL message to the worker. The worker calls
ffmpeg.setTimeout(1), setting the WASM watchdog to fire after 1 ms,
stopping the current command as quickly as possible (exit code 1)
without terminating the entire worker.

Changes:
- const.ts: add FFMessageType.CANCEL
- worker.ts: add cancel() handler calling ffmpeg.setTimeout(1)
- classes.ts: send CANCEL on exec/ffprobe abort

Closes ffmpegwasm#719

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@JacobiusMakes JacobiusMakes force-pushed the fix/abort-signal-cancels-exec branch from e297b86 to 50f33d3 Compare March 27, 2026 05:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Abort signal received by worker, but the process continues.

1 participant