After Upgrade to Django 5.2.9, Some Warnings from easy_thumbnail's thumbnail_cleanup

[jonfroehlich]

When we start the server, we run a script that also executes a series of cleanup commands (to remove stale or unused files from the filesystem). One of these commands is python manage.py thumbnail_cleanup, which executes easy_thumbnail's built-in thumbnail_cleanup command to remove old unused thumbnails. However, Django 5.2.9 changed how it handles default storage, so we get this warning.

The warnings are harmless—the cleanup command is just skipping orphaned records it can't locate. The site should still work fine. The thumbnails themselves will regenerate as needed.

website-1  | ****************** STEP 4.1/5: docker-entrypoint.sh ************************
website-1  | 4.1 Running 'python manage.py thumbnail_cleanup' to delete unused thumbnails
website-1  | ******************************************
website-1  | CONFIG_FILE: /code/config.ini
website-1  | DJANGO_ENV: None
website-1  | DEBUG_SET: DEBUG was set by /code/config.ini file
website-1  | DEBUG: True
website-1  | System check identified some issues:
website-1  |
website-1  | WARNINGS:
website-1  | Source storage hash (f9bde26a1556cd667f742bd34ec7c55e) not found in STORAGES
website-1  | Can't determine source storage, skipping source
website-1  | Source storage hash (f9bde26a1556cd667f742bd34ec7c55e) not found in STORAGES
website-1  | Can't determine source storage, skipping source
website-1  | Source storage hash (f9bde26a1556cd667f742bd34ec7c55e) not found in STORAGES
website-1  | Can't determine source storage, skipping source
website-1  | Source storage hash (f9bde26a1556cd667f742bd34ec7c55e) not found in STORAGES
website-1  | Can't determine source storage, skipping source
website-1  | Source storage hash (f9bde26a1556cd667f742bd34ec7c55e) not found in STORAGES
website-1  | Can't determine source storage, skipping source
website-1  | Source storage hash (f9bde26a1556cd667f742bd34ec7c55e) not found in STORAGES
website-1  | Can't determine source storage, skipping source
website-1  | Source storage hash (f9bde26a1556cd667f742bd34ec7c55e) not found in STORAGES
website-1  | Can't determine source storage, skipping source
website-1  | Source storage hash (f9bde26a1556cd667f742bd34ec7c55e) not found in STORAGES
website-1  | Can't determine source storage, skipping source
website-1  | Source storage hash (f9bde26a1556cd667f742bd34ec7c55e) not found in STORAGES
website-1  | Can't determine source storage, skipping source
website-1  | Source storage hash (f9bde26a1556cd667f742bd34ec7c55e) not found in STORAGES
website-1  | Can't determine source storage, skipping source
website-1  | Source storage hash (f9bde26a1556cd667f742bd34ec7c55e) not found in STORAGES
website-1  | Can't determine source storage, skipping source
website-1  | Source storage hash (f9bde26a1556cd667f742bd34ec7c55e) not found in STORAGES
website-1  | Can't determine source storage, skipping source
website-1  | Source storage hash (f9bde26a1556cd667f742bd34ec7c55e) not found in STORAGES
website-1  | Can't determine source storage, skipping source
website-1  | Source storage hash (f9bde26a1556cd667f742bd34ec7c55e) not found in STORAGES
website-1  | Can't determine source storage, skipping source
website-1  | Source storage hash (f9bde26a1556cd667f742bd34ec7c55e) not found in STORAGES
website-1  | Can't determine source storage, skipping source
website-1  | Source storage hash (f9bde26a1556cd667f742bd34ec7c55e) not found in STORAGES
website-1  | Can't determine source storage, skipping source
website-1  | Source storage hash (f9bde26a1556cd667f742bd34ec7c55e) not found in STORAGES
...

[jonfroehlich]

Diagnosis & impact assessment

TL;DR: harmless log noise, but there's one minor real consequence. Low priority, still relevant.

Root cause

easy_thumbnails keeps a DB index of source files (easy_thumbnails_source). Each row stores a storage_hash — a fingerprint of the storage backend that created it (computed by pickling the storage object).

Django 4.2/5.x deprecated DEFAULT_FILE_STORAGE in favor of the new STORAGES dict, which changed how the default storage object is constructed. So the live storage now fingerprints to a different hash (f9bde26a…) than the one baked into our existing DB rows. When thumbnail_cleanup walks those rows it can't match the stored hash to any configured storage → "Can't determine source storage, skipping source".

We don't define a STORAGES setting in settings.py, so we're on Django's default, and the command still runs on every container start (docker-entrypoint.sh).

Impact

• Site thumbnails: unaffected. Images render and regenerate on demand as normal.
• The one real consequence: since thumbnail_cleanup skips every source, it's now effectively a no-op. Its job is to delete orphaned thumbnails from disk, so stale/unused thumbnails will slowly accumulate in media/. That's a slow disk-bloat trickle — negligible for a long time, not a correctness/availability issue.

Fix options (not urgent)

1. Real fix — clear the easy_thumbnails index tables. The easy_thumbnails_source / easy_thumbnails_thumbnail rows are just a cache; actual images live on disk and regenerate on demand. Deleting the rows lets new ones be written with the current storage hash, after which thumbnail_cleanup matches and works again. Given our server-access model (no direct prod DB access), this would ship as a one-shot management command wired into the entrypoint before the thumbnail_cleanup step.
2. Silence only — reduce verbosity / accept the noise. Hides the symptom but leaves cleanup non-functional, so not really worth it.

Recommendation: leave as-is for now (genuinely low impact); if/when addressed, go with option 1, since it both kills the warning and restores cleanup.