GMAIL: Getting digest/container update emails for containers that have no updates

[begunfx]

Drydock version

1.5.0-rc.5

What happened?

I know we had discussed issues recently related to Gmail notifications. The latest behavior most likely is related. I just got two emails for containers to update, but there are no updates for those containers. Wondering if there is something that is stuck in the dd.json that is indicating the containers have updates that aren't being cleared properly?

What did you expect?

see above

Steps to reproduce

See above

Relevant configuration

Logs

Installation method

Docker Compose

Docker version

24.0.1

OS / Architecture

Synology DSM 7

[s-b-e-n-s-o-n]

Thanks for the report — this is a confirmed bug in the digest notification system.

Root cause: The digest buffer stores container snapshots when an update is first detected, then sends them when the digest cron fires (default 8am). Two problems:

1. No eviction on state change — if a subsequent watcher scan finds a container no longer has an update, the stale buffer entry was never removed
2. No revalidation at flush time — flushDigestBuffer() sent whatever was buffered without re-checking current store state

So if a container was updated between the scan that detected the update and the digest cron firing, you'd get a phantom email.

Fix (on feature/v1.5-rc6):

• handleContainerReportDigest() now evicts buffer entries as soon as a later report arrives with updateAvailable: false
• flushDigestBuffer() now revalidates every buffered entry against current store state before dispatch — stale entries are silently dropped

This will ship in RC6. The #265 race guard (also RC6-only) further reduces the window where stale state can re-enter the buffer after a manual update.

[begunfx]

This is likely resolved but it might be best to keep this open until we can resolve the other email related issues to be sure: #228 and #282

[s-b-e-n-s-o-n]

Re-verified the RC6 fixes against current code on the next-RC branch. Everything is still in place:

• flushDigestBuffer revalidates every buffered entry against current store state at flush time and silently drops anything that no longer has updateAvailable=true (Trigger.ts:1620-1690). A flush with nothing left logs Digest cron fired — no buffered updates remain after revalidation and sends no email.
• handleContainerReportDigest evicts an entry as soon as a later per-container report arrives with updateAvailable=false (Trigger.ts:988-998), so the buffer never holds stale state between cron fires.
• handleContainerReports additionally evicts any digest-buffered entries after a successful batch send, which closed the rc.7 double-send path (Trigger.ts:1488-1495, 982b4d74).
• 06e8a4ee prevents a stale result from pre-clear watcher scans from re-entering the buffer after a manual update completes.

#228 is confirmed closed by you, and #282's rc.7 email-pipeline fixes have all landed, so the dependencies you wanted to wait on are resolved.

I'm going to call this one done on the code side. Please keep it open on your end until you've had a few digest cycles on the next RC; if a phantom still shows up there, the logs around the flush will point at which eviction path missed it and we can reopen with the data in hand. Otherwise feel free to close when you're satisfied.