You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
load_video() leaks temporary files when remote video decoding fails #14994
diffusers.utils.load_video() creates a temporary file using NamedTemporaryFile(delete=False) when downloading a video from a URL. However, the temporary file is removed only after video decoding completes successfully.
If decoding raises an exception (for example, when attempting to load a corrupted GIF), execution never reaches the cleanup statement, leaving the downloaded file on disk.
Repeated failures may accumulate unnecessary temporary files.
Steps to reproduce
The following reproduction uses a mocked HTTP response and requires no GPU or external network access.
The decoder raises UnidentifiedImageError, but the temporary file remains on disk.
Observed output:
Exception: UnidentifiedImageError
Remaining temporary files:
tmpeiv6c3cc.gif | Size: 23 bytes
BUG REPRODUCED: Temporary file was not deleted!
Expected behavior
Temporary files created for remote video downloads should be deleted even when downloading or decoding fails. The original exception should continue to propagate.
Root cause
In src/diffusers/utils/loading_utils.py:
Line 97 creates a temporary file with delete=False.
The subsequent code downloads and decodes the video.
Line 142 removes the temporary file only after successful decoding.
Any exception before the cleanup statement bypasses file deletion.
Proposed fix
Ensure exception-safe cleanup of downloaded temporary files using try/finally, covering both download and decoding failures.
Add regression tests verifying that temporary files are removed on both successful and failed operations.
@sayakpaul I am really sorry for not discussing this and disrupting the contributor guidelines. I reproduced the issue locally and verified the changes with regression tests, but I understand that the implementation approach should have been discussed first. Will make sure to seek maintainer feedback before opening PRs in the future.
@sayakpaul just would like to know about whether this approach is correct or not... or if it needed any corrections or improvisations. Would love to discuss.
Activity
sayakpaul commentedon Oct 9, 2026
Cc: @DN6
@SrijanRoy123-github we didn't even discuss the proposed fix before the PR. It'd be nice if we didn't do that going forward.
BlazeSR10hawk commentedon Oct 9, 2026
@sayakpaul I am really sorry for not discussing this and disrupting the contributor guidelines. I reproduced the issue locally and verified the changes with regression tests, but I understand that the implementation approach should have been discussed first. Will make sure to seek maintainer feedback before opening PRs in the future.
BlazeSR10hawk commentedon Oct 22, 2026
@sayakpaul just would like to know about whether this approach is correct or not... or if it needed any corrections or improvisations. Would love to discuss.