False "update failed (404 / 409)" notifications after successful auto-update

[tarzan77cz]

Drydock version

1.5.0-rc.29

What happened?

When using automatic updates via dd.action.include (e.g., dockercompose.stacks), the update successfully completes and sends an updated successfully notification. However, a few minutes later, ghost update failed notifications arrive with HTTP 404 (No such container) or HTTP 409 (Conflict).

The containers are updated correctly and running fine, but the notification system spams failures for dead operations.

What did you expect?

If an auto-update succeeds, no secondary "ghost" operations should fail and trigger update-failed notifications.

Steps to reproduce

It looks like a race condition where a container report is enqueued multiple times (e.g. from both handleContainerReport and handleContainerReports, or from subsequent watcher cron passes before the first operation clears the queue).

The first operation succeeds and recreates the container (new ID).
The duplicate operation eventually executes but holds the snapshot with the old Docker ID.
It hits the Docker API (gets 404) or agent API (gets 409), the operation is marked terminal as failed, and Trigger.ts blindly emits the update-failed notification to Telegram/Pushover.

Relevant configuration

Logs

Logs / Symptoms:

[03.06.2026 12:00] New tag found for container n8n
[03.06.2026 12:05] Container prowlarr updated successfully
[03.06.2026 12:06] Container n8n updated successfully
[03.06.2026 12:11] Container n8n update failed: (HTTP code 404) no such container - No such container: 33f037...
(Similarly, on agent-hosted containers, it throws Request failed with status code 409 instead of 404).

Installation method

Docker Compose

Docker version

29.3.0

OS / Architecture

Linux docker 6.11.11-2-pve

[scttbnsn]

Hi @tarzan77cz — this is fixed in v1.5.0-rc.30, just published.

Root cause: after a successful update, a duplicate update operation could run against a container that had already been recreated (by a previous pass, Docker Compose, or an agent), hitting a genuine Docker 404 no such container / 409 conflict. That was terminalised as failed and fired a false "update failed" notification — even though your update had actually succeeded.

Fix: rc.30 reclassifies these benign post-success errors to a non-notifying expired status (only when a matching successful update for the same container exists within a 15-minute window — a real failure with no recent success still notifies as before), and repairs the duplicate-operation detection so the stale operation is blocked up front instead of executing.

Please pull rc.30 and let me know if you still see any false failure notifications:

• ghcr.io/codeswhat/drydock:1.5.0-rc.30
• codeswhat/drydock:1.5.0-rc.30

Thanks for the clear report — it's exactly what made this one findable.

[scttbnsn]

One more update here — the branch that's going into v1.5.0-rc.35 closes the residual race that could still produce a false "update failed" notification in your setup.

What rc.30 fixed (the original report): after a successful update, a stale duplicate operation would run against the already-replaced container, hit a Docker 404/409, and get terminalized as failed — firing the false notification. That was fixed by reclassifying those errors as expired (silent) whenever a recent succeeded operation exists for the same container within a 15-minute window.

What rc.35 fixes (the residual race, issue #421): there's a narrow window where the winner of a duplicate-update race is still in-progress when the loser gets its 409 back — so no succeeded row exists yet at classification time, and the loser was falling through to failed. The fix adds an active-operation check: if another in-progress or queued operation exists for the same container and agent identity (excluding the loser's own row), the 409 is provably benign and the loser is marked expired instead. Strict identity matching ensures an identically-named container on a different agent can't accidentally suppress a genuine failure on this one.

Could you pull rc.35 once it's published and confirm the false failure notifications are gone? If you're not seeing them anymore we'll close this out — thanks again for the detailed original report.

• ghcr.io/codeswhat/drydock:1.5.0-rc.35
• codeswhat/drydock:1.5.0-rc.35