Getting email updates via SMTP after the container has been updated

[begunfx]

Drydock version

1.5.0-rc.1

What happened?

I updated two containers and then got the following email example:

- Container Stirling-PDF running with digest
sha256:<redacted> can be
updated to digest
sha256:<redacted>

This was POST update.

What did you expect?

Not to get an email after update a container and that is irrelevant to the action taken.

Steps to reproduce

see above

Relevant configuration

Logs

Installation method

Docker Compose

Docker version

1.5.0-rc.1

OS / Architecture

Synology DSM 7

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

Thanks @begunfx — this is the same root cause as #229.

After a manual container update via the UI, the updateAvailable flag wasn't being cleared in the store. When the watcher's next scan cycle fired (triggered by Docker events from the container recreation), it still saw the flag as true and the notification trigger sent the email.

The fix in #229 clears updateAvailable immediately after the update trigger completes, before the watcher's debounced scan runs. This prevents both the stale dashboard row (#229) and the spurious notification email (this issue).

Will ship in the next RC build alongside #229.

[begunfx]

This is still happening in 1.5.0-rc.2. Getting emails about an update AFTER the container was just updated.

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

Found the real root cause — the previous fix was targeting a symptom, not the actual problem.

What was actually happening: updateAvailable is not a stored field — it's derived from result data every time the container model is validated. The RC2 fix tried to set updateAvailable = false directly, but the model's validation logic immediately recomputes it from the stale result payload. So the write was effectively a no-op: the store still saw the container as having an update available, and SMTP triggers kept firing.

What we fixed for rc.3:

• Instead of trying to clear the derived boolean, we now clear the raw update state (result, updateKind, etc.) that feeds the computation — using a new clearDetectedUpdateState() helper
• This is applied in both the manual update path (container-actions API) and the agent event path
• Added a regression test against the real model/store recomputation to prove updateAvailable actually transitions to false after the fix — the previous tests only asserted against mocks and never caught this

This will ship in rc.3 — please verify once it's out.