Skip to content

firstCheckNotif: false not preventing repeat notification across separate "first checks" #1785

Description

@mwcassens

I'm seeing the same image/digest trigger a notification on two separate days, despite firstCheckNotif set to false. The image is docker.io/library/redis:7.4.9-alpine, digest sha256:6ab0b6e7381779332f97b8ca76193e45b0756f38d4c0dcda72dbb3c32061ab99, created May 07, 2026 17:34:49 UTC.

duin issue 1.rtf

Day 1: deleted the Diun database (diun.db), then ran Diun for the first time with this image being watched via watchRepo. Received a notification for this tag/digest with wording "is available" (the new-image phrasing, not the updated-image phrasing).

Day 2 (next scheduled run, ~18 hours later, database NOT deleted in between): received the exact same notification again, for the exact same tag and exact same digest, again with "is available" phrasing - suggesting Diun treated this as a first-time discovery a second time, rather than recognizing it had already recorded this tag/digest the previous day.

Config relevant settings:
DIUN_WATCH_FIRSTCHECKNOTIF=false
DIUN_DEFAULTS_WATCHREPO=true
DIUN_DEFAULTS_MAXTAGS=5
DIUN_DEFAULTS_SORTTAGS=semver
DIUN_PROVIDERS_DOCKER_WATCHBYDEFAULT=true

Expected behavior:
Once a tag/digest has been recorded by Diun, firstCheckNotif: false should prevent it from being treated as a "new" first-time discovery again on a subsequent run, as long as the database persists between runs.

Actual behavior:
The same tag/digest triggered an "is available" (first-discovery-style) notification twice, on two consecutive daily runs, with no database deletion in between.

Diun version: v4.33.0

Logs provided and attached

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions