Repository navigation
Container recreate causes old/historical tags to be re-notified as "available" (related to #541, still present in v4.33.0) #1786
Description
After recreating the Diun container itself (docker compose up -d --force-recreate, to apply an updated DIUN_DEFAULTS_EXCLUDETAGS env var), the very next scheduled run sent 14 notifications for old, historical image tags - some over a year old - all using the "is available" (first-discovery) phrasing rather than "has been updated".
This looks related to #541 (from 2022, still open), which describes every historical Diun version tag flooding in on first run with firstCheckNotif enabled. My case differs slightly: firstCheckNotif is set to FALSE, and this isn't the very first run ever - the database file was NOT deleted and had already recorded these tags in a previous run. Only the Diun container itself was recreated (new container ID). That alone appears sufficient to cause previously-seen tags to be re-treated as first-time discoveries.
Examples from the batch (all triggered by the new container ID, different from the previous container's ID):
- lscr.io/linuxserver/sonarr:4.0.15 (created Oct 24, 2025)
- lscr.io/linuxserver/radarr:5.27.5 (created Oct 12, 2025)
- lscr.io/linuxserver/lidarr:2.13.3 (created Oct 08, 2025)
- docker.io/apache/tika:2.5.0 (created Oct 09, 2022)
...and 10 others, all well outside the maxTags:5 + sortTags:semver window that should apply to current watching.
Config:
DIUN_WATCH_FIRSTCHECKNOTIF=false
DIUN_DEFAULTS_WATCHREPO=true
DIUN_DEFAULTS_MAXTAGS=5
DIUN_DEFAULTS_SORTTAGS=semver
DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT=true
Expected behavior:
Recreating the watching container (with the database volume persisted/unchanged) should not cause previously-seen tags to be re-treated as new discoveries, especially with firstCheckNotif explicitly set to false.
Actual behavior:
14 old, already-seen tags were re-notified as newly available immediately after a container recreate.
Diun version: v4.33.0
Given #541 has been open since 2022 with the same underlying symptom (mass re-discovery of historical tags), it would be helpful to know if this is considered expected/by-design behavior, or a genuine bug worth fixing - since as configured, firstCheckNotif: false does not appear to actually prevent this scenario.
Logs provided
Activity
hiSandog commentedon Jul 11, 2026
The persisted database plus changed container ID seems like a useful regression boundary to capture in a test: run discovery once, recreate only the watcher container while mounting the same DB, then assert that the second run emits no first-discovery notifications. It may also help diagnosis if the debug logs show the exact persisted provider/watch key used for each image before and after recreation; that would reveal whether container identity is accidentally part of the key even though the tag history still exists.