Triggering a container update and navigating away and back to container view resets updating state

[begunfx]

Drydock version

1.5.0-rc.3

What happened?

I triggered an individual container update, then navigated away from the container page. I went back to see that the updating state was gone and reset to update available state. I triggered an update again. This time I got a 500 error (I also saw a 409 conflict error in the logs). I assume that the update did start to run, and when I tried to start it again, I hit the conflict. Drydock needs to be able to persist the updating state even if navigating away from the view that the update was triggered on so we don't have any collisions like this.

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]

Found the root cause — the in-progress update operation was persisted in the backend store, but it wasn't being surfaced in the container list API response. So when the UI refetched containers (on navigation or SSE events), the "Updating" state was lost because the API didn't include the operation data.

The fix plumbs the update operation state end-to-end:

• Backend list endpoint now enriches container responses with any in-progress update operation
• UI container mapper picks up the updateOperation field
• useContainerActions and useDashboardComputed consume it to restore the "Updating" visual state after refetch/navigation

This will ship in the next RC. The update lifecycle now survives page navigation, SSE-triggered refreshes, and manual reloads.

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

Fixed in v1.5.0-rc.4. Please update and let us know if this resolves the issue.

[begunfx]

Tested. This is still happening in v1..5.0-rc.4. I triggered an update for a container in container view. Navigated away and back and the update process was cleared and it was back to the pre-update/update available state.

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

Thanks for retesting on RC4 — confirmed this wasn't actually fixed.

Root cause: When a container update replaces the container, the new container gets a fresh Docker ID. The update operation stored the old container's ID, so when the API tried to match the in-progress operation to the container on refetch, the IDs didn't match and the "Updating" state was dropped.

Fix: The operation lookup now also checks the replacement container ID (newContainerId), so the in-progress state survives the ID change during updates. This preserves the same-name container guardrails from #256.

This will ship in the next RC. Verified with 6,100 tests at 100% coverage.

[begunfx]

I also noticed a similar behavior when trying to update a container, then trigger another update. The previous container would leave the updating state and go back to the update available state. Is it safe to assume it's related here?

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

Yes, same root cause. When container A's update replaces the Docker container (new ID), the in-progress operation was stored under the old ID. The API couldn't match it to the new container, so the "Updating" state dropped back to "Update available" on refetch.

The fix in RC5 adds newContainerId lookup so the operation stays attached through the ID change. This covers both your scenarios — navigating away and triggering a second update while one is running.

(The separate issue of one update blocking another was already fixed in RC2 via per-container action tracking.)

[begunfx]

I can confirm that the issue blocking further container updates if one is running does seem to be working now in rc.4. 👍

[begunfx]

So a new issue related to this just appeared as of rc.6. I triggered an update for a container (in the container view), then tried to navigate away to any other menu item (Dashboard, Security etc.) but I wasn't able to. Was completely blocked from being able to navigate anywhere until the update completed.

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

Thanks for the follow-up on RC6 — the navigation blocking issue you described is a separate bug from the original state-loss problem, and we've identified and fixed the root cause.

What was happening: When you triggered a container update, the API request held the HTTP connection open for the entire Docker lifecycle (image pull → stop → create → start → health check → cleanup). Meanwhile, Docker events during the update fired rapid container-list refreshes over SSE, and the router's auth check needed its own network request to navigate. On HTTP/1.1 (which has a 6-connection-per-origin limit), these combined to exhaust the browser's connection pool — so clicking Dashboard, Security, etc. queued the auth request behind everything else and navigation hung until the update finished.

What we fixed (three changes):

1. Container update endpoint returns immediately. POST /containers/:id/update now returns 202 Accepted with an operationId right away, instead of blocking until the full Docker lifecycle completes. The update runs in the background and the UI tracks progress through the existing update operation polling.

2. SSE container-changed events are debounced. During an update, Docker emits 4–6 rapid events (rename, create, stop, start, etc.). Previously each one triggered an immediate full container list reload. Now they're debounced to a single reload within 500ms.

3. Auth check is cached. The navigation guard's user check now uses a short-lived cache (5 seconds) with in-flight request deduplication, so navigating between pages doesn't depend on a fresh network request every time.

The original state-loss fix (update operation tracking through container ID changes) is confirmed working on RC6 and is unaffected by these changes.

This will ship in the next RC. The update toast will now say "Update started" instead of "Updated" to reflect the asynchronous flow — you'll see the container transition through the updating state via the existing operation status polling.

[begunfx]

This seems to be working now with the caveat I called out in #289 and duplicate of #256 (maybe). Technically this I think is solved as I was able to navigate away during an update and back and was able to see that the container was still updating (just with the wrong state - queued listed). So, long story short, I think you can close this. Thanks!

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

This has been addressed in the upcoming RC with several fixes across both the backend and UI:

• API-level guard against duplicate container updates — the backend now returns a proper conflict response if an update is already in progress, preventing the 500 errors you saw (110aae36)
• Backend-driven update queue — update state is now tracked server-side with per-trigger concurrency limits, so the UI reflects the real state regardless of navigation (bacbc1c7)
• UI defers to backend queue status — instead of relying on local component state that gets lost on navigation, the UI now reads the update state from SSE events pushed by the server (95c0d530)
• Stable container identity scoping — update state is keyed by container ID, not name, to prevent cross-container state confusion (05c023fe, related to Updating one portainer_agent momentarily makes another one look like it's updating #256)

The next RC will be out shortly — please test the navigate-away-and-back scenario and let us know if the state holds correctly now.