Media that takes too long to process no longer stays on Processing

While Anthias prepares an upload or downloads a video, the asset shows "Processing" in the asset table. If that fails, the row shows "Failed", and clicking it opens the asset with the reason. Anthias 2026.10.0 fixes the cases where a slow job never got that far.

Jobs that run too long

Five of these jobs had only a hard time limit: reading a video's duration, preparing an image, preparing a video, downloading from YouTube and downloading a video from a URL. One that ran over was killed on the spot with no chance to update the asset, so the asset stayed on "Processing" with nothing to say why.

From Anthias 2026.10.0, each of them gets a warning 30 seconds before its hard limit and stops cleanly. An image or video that runs out of time while being prepared or downloaded shows "Failed" with a message such as "Timed out: processing did not finish within 270s". A video whose duration can't be read in time leaves "Processing" without a message. The limits themselves are the same as before: 2 minutes to read a video's duration or prepare a video, 5 minutes to prepare an image, and 15 minutes for a download.

Images over the size limit

Anthias refuses images over 50 megapixels. An image between 50 and 100 megapixels already said so, in a message written for developers. One over 100 megapixels, such as a large scan or a poster export, failed with the image library's own warning about a possible "decompression bomb DOS attack", which sounds far worse than an image that's too big. Now both say how big the image is, that the limit is 50,000,000 pixels, and to resize it and upload again.

Expected failures stop looking like crashes

A YouTube link that YouTube refuses (a 403 or 404, an age restriction, a region block), an image over the limit, and a source file that's gone by the time processing starts, for example because you deleted the asset while it was processing, are expected outcomes. The worker log now records them as a single line instead of an error with a traceback, and they're no longer sent as crash reports. If you point crash reporting at your own Sentry project with SENTRY_DSN, they stop showing up there too. The asset table shows the same as before: a YouTube refusal still shows "Failed" with YouTube's reason, and a deleted asset is gone.