Media: Add timeout and size guardrails to client-side GIF to video conversion

[adamsilverstein]

What?

Fixes #80376.

Adds two guardrails to client-side GIF → video conversion so pathological GIFs degrade gracefully instead of churning the CPU, plus a queue fix discovered while verifying them against a real-world problem GIF:

1. Total-pixel budget (skip up front). convertGifToVideo in @wordpress/video-conversion now rejects GIFs whose total decoded pixels (width × height × frame count) exceed a budget (default 300 megapixels, exported as DEFAULT_MAX_TOTAL_PIXELS) before any encoding work. The rejection reuses the Unsupported message-prefix contract, so callers take the existing graceful-skip path: the GIF uploads normally, no companion video, no user-facing error.
2. Conversion timeout (default 30 seconds). @wordpress/upload-media races the conversion against a timeout. On expiry the worker-side operation is cancelled and only the uploaded GIF is kept.
3. cancelItem no longer awaits worker cancellations. A busy vips worker is synchronously blocked inside a wasm call and cannot answer a cancellation RPC until everything already queued in the worker finishes. Awaiting the best-effort cancels left cancelled items stuck in the queue — and the parent attachment unfinalized — for minutes. They are now fire-and-forget.

Both knobs are configurable via the TranscodeGif operation args (timeout, maxTotalPixels; 0 disables). Skips are logged as SCRIPT_DEBUG diagnostics (via the existing debug() helper), and processItem now logs each operation start under SCRIPT_DEBUG for easier pipeline debugging.

Why?

During testing on #80260, uploads of large screen-recording GIFs appeared to hang (report, test files): one conversion ran for 30 minutes on a MacBook Air. The companion video is a progressive enhancement — when it is expensive, the right move is to skip or abandon it silently.

Debugging findings (the 2026-07-10 14.44.24.gif test image)

That GIF is 2554×1676 with 800 frames (3.42 gigapixels total, 20 MB file). Measurements with wasm-vips and a store tracer in the editor:

Operation	Time
Animated sub-size, 150px ([n=-1], gifsave)	84 s
Animated sub-size, 300px	91 s (56 s in-browser)
First-frame-only sub-size, 1024px	1.9 s
Pixel-budget rejection of the conversion (this PR)	~0.1 s

Two distinct problems compound into the observed "stuck uploading" state:

• The sub-size grind: every animated sub-size decodes all 800 source frames (a ~80 s floor each, plus re-quantization that grows with output size). The medium_large/large/1536x1536/2048x2048 chain takes tens of minutes, and in one run the tab crashed outright. The conversion itself (the thing this PR bounds) took only ~10 s by comparison. Client-side media: generate animated image sub-sizes from the first frame only, matching core #80268 fixes that side by generating animated sub-sizes from the first frame only, matching core; with both PRs this GIF uploads in seconds.
• The blocked cancel: even after the new budget check skipped the conversion in ~0.1 s, the item stayed PROCESSING — cancelItem was awaiting a cancellation RPC that the busy vips worker could not answer. That is fix 3 above, proven by a unit test where the worker never responds.

How?

• packages/video-conversion: budget check right after decoder.tracks.ready, using a cheap first-frame decode to learn dimensions (track metadata does not expose them). New SIZE_LIMIT_ERROR_PREFIX and DEFAULT_MAX_TOTAL_PIXELS exports.
• packages/upload-media: Promise.race timeout around the worker call in convertGifToVideo, cancelling the worker-side operation on expiry; new isSizeLimitConversionError / isConversionTimeoutError helpers mirroring the existing message-prefix contract; graceful skip + SCRIPT_DEBUG diagnostics in transcodeGifItem; fire-and-forget worker cancels in cancelItem.

Testing Instructions

1. Upload a normal (small) animated GIF to a post. It should still get a companion video (check the attachment's animated_video metadata / the GIF variation transform on the block).
2. Upload a huge GIF, e.g. 2026-07-10 14.44.24.gif (2554×1676 × 800 frames). With SCRIPT_DEBUG enabled the console logs [upload-media] Skipping GIF to video conversion: Unsupported: GIF exceeds maximum conversion size (2554x1676 x 800 frames = 3424403200 pixels; limit is 300000000) almost immediately, and the queue item is cancelled right away instead of lingering. The GIF itself uploads fine.
   • Note: until Client-side media: generate animated image sub-sizes from the first frame only, matching core #80268 lands, sub-size generation for such a GIF still takes a long time; that is a separate code path from the conversion bounded here.
3. npm run test:unit -- packages/video-conversion packages/upload-media

Notes

• The 300 MP default is a first calibration (a mid-range machine converts roughly that much within the 30 s timeout); happy to tune it based on review feedback.
• Follow-up worth tracking separately: a worker-RPC-level timeout would make a wedged worker recoverable for everything queued behind it (see the notes in Client-side media: add timeout and size guardrails to GIF to video conversion #80376 and Upload queue: a vips worker failure leaves uploads hanging forever (worker RPC promises never settle) #79953).

[github-actions]

Size Change: +537 B (+0.01%)

Total Size: 7.73 MB

📦 View Changed

Filename	Size	Change
build/modules/video-conversion/worker.min.js	83.6 kB	+225 B (+0.27%)
build/scripts/upload-media/index.min.js	15.5 kB	+312 B (+2.05%)

_{compressed-size-action}

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: adamsilverstein <adamsilverstein@git.wordpress.org>
Co-authored-by: andrewserong <andrewserong@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Size Change: +535 B (+0.01%)

Total Size: 7.73 MB

📦 View Changed

Filename	Size	Change
build/modules/video-conversion/worker.min.js	83.7 kB	+223 B (+0.27%)
build/scripts/upload-media/index.min.js	15.5 kB	+312 B (+2.05%)

_{compressed-size-action}

[andrewserong]

Just giving this a tentative approval as I really like the guards that it adds! In practice while testing it I'm still getting the hanging issue that will be resolved by #80268. I.e. stuck in this state:

Am I right in assuming that it's expected that this PR will still be hanging because it's still taking ages to process all the source frames, so the timeout and guards in this PR won't be applying yet as we're stuck in a different part of the pipeline? My assumption is that once that other PR lands, then the guards here will work.

In the interest of time, and since the code looks good to me, I'll give this the ✅ as I'm nearing my weekend 😄

So, once #80268 lands, feel free to merge this if it fixes the issue for you. If you'd like further testing before landing, happy to give this another look next week!

[adamsilverstein]

Am I right in assuming that it's expected that this PR will still be hanging because it's still taking ages to process all the source frames, so the timeout and guards in this PR won't be applying yet as we're stuck in a different part of the pipeline? My assumption is that once that other PR lands, then the guards here will work.

thats right. This adds guards that protect against overly long GIF->Video conversion. With your test image, that only takes <10 seconds though for me - the thing that seems to hang the process is converting the GIF into all of the subsizes and re-encoding animation for each of those subsizes.

Maybe on the other ticket where I am proposing enabling this conversion with a filter we should consider showing progress in the snackbar when this is enabled "Generating sub-size x of y" since it can take so long.

So, once #80268 lands, feel free to merge this if it fixes the issue for you. If you'd like further testing before landing, happy to give this another look next week!

I'll merge 80268 first then this one.

[github-actions]

There was a conflict while trying to cherry-pick the commit to the wp/7.1 branch. Please resolve the conflict manually and create a PR to the wp/7.1 branch.

PRs to wp/7.1 are similar to PRs to trunk, but you should base your PR on the wp/7.1 branch instead of trunk.

# Checkout the wp/7.1 branch instead of trunk.
git checkout wp/7.1

# Create a new branch for your PR.
git checkout -b my-branch

# Cherry-pick the commit.
git cherry-pick 8852382c3609374c0c7542593a8796e3f54452e3

# Check which files have conflicts.
git status

# Resolve the conflict...
# Add the resolved files to the staging area.
git status
git add .
git cherry-pick --continue

# Push the branch to the repository
git push origin my-branch

# Create a PR and set the base to the wp/7.1 branch.
# See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.

[github-actions]

Flaky tests detected in db82d82.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/29559214925
📝 Reported issues:

• [Flaky Test] Should insert content using the global inserter #78924 in /test/e2e/specs/widgets/editing-widgets.spec.js
• [Flaky Test] should update the HTML only for the latest navigation #78835 in /test/e2e/specs/interactivity/router-navigate.spec.ts

[t-hamano]

@adamsilverstein, Can you backport this PR manually to the wp/7.1 branch?

[github-actions]

There was a conflict while trying to cherry-pick the commit to the wp/7.1 branch. Please resolve the conflict manually and create a PR to the wp/7.1 branch.

PRs to wp/7.1 are similar to PRs to trunk, but you should base your PR on the wp/7.1 branch instead of trunk.

# Checkout the wp/7.1 branch instead of trunk.
git checkout wp/7.1

# Create a new branch for your PR.
git checkout -b my-branch

# Cherry-pick the commit.
git cherry-pick 8852382c3609374c0c7542593a8796e3f54452e3

# Check which files have conflicts.
git status

# Resolve the conflict...
# Add the resolved files to the staging area.
git status
git add .
git cherry-pick --continue

# Push the branch to the repository
git push origin my-branch

# Create a PR and set the base to the wp/7.1 branch.
# See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.

[adamsilverstein]

@adamsilverstein, Can you backport this PR manually to the wp/7.1 branch?

yes, will do.

[adamsilverstein]

@t-hamano - backport:

• [7.1 Backport] -- Media: Add timeout and size guardrails to client-side GIF to video conversion #80420

[t-hamano]

Removing the Backport to Gutenberg RC label from this PR and add it to #80420 instead. This is because cherry-picking the manual backport PR created for wp/7.1 is less likely to cause conflicts than cherry-picking the PR that caused the conflict.

[t-hamano]

This PR was manually backported to wp/7.1 by #80420.