Updating one portainer_agent momentarily makes another one look like it's updating

[begunfx]

Drydock version

1.5.0-rc.4

What happened?

Not sure how else to describe this, but when I trigger an update of one of the portainer_agents, the others momentarily go into an updating state (greyed out), then return to normal shortly after.

What did you expect?

Only the selected container going into an updating state - leaving the others alone.

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 reporting this @begunfx — tracked it down and fixed it.

Root cause

When the API returns the container list, it attaches any in-progress update operation to each container so the UI can show the "Updating" state. The lookup was by container name only (getInProgressOperationByContainerName), so when you have multiple portainer_agent containers across different hosts, updating one caused the API to attach that operation to all containers with the same name — making them all briefly grey out.

Fix (commit a6d03a74)

1. Backend store: Added getInProgressOperationByContainerId() — queries by the unique container ID instead of the shared name.
2. API layer: attachInProgressUpdateOperation() now tries ID-based lookup first, falling back to name only for legacy operations that predate the containerId field.
3. Frontend: getContainerActionKey() now prefers container ID over name for action tracking, preventing same-named containers from sharing action state.

This will ship in RC5. Please verify once it's out!

[begunfx]

Running version rc.6. I updated one of my docker-socket-proxy containers (all of them have updates). I updated one of them from the Container View>Stacks View. Just after triggering one of them to update all of the other docker-socket-proxy containers briefly when into an updating state, then when the one I actually triggered completed the others returned to an update available state. This scenario is: multiple containers of the same name/service across multiple hosts grouped together in the stack view and triggering an update of just one of the containers - hope that helps hunt this down.

Screenshot for reference (this is after I updated one of them)

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

Thanks for the follow-up @begunfx — you're right, this is still happening. The RC5 backend fix was correct but incomplete: the frontend's pending-action state was still keyed by container name, so updating one docker-socket-proxy would briefly mark every same-named container as pending across all hosts.

Root cause (RC7 fix)

The RC5 fix (a6d03a74) addressed the backend API and store layers (ID-based operation lookup) and changed getContainerActionKey() to prefer ID. But the pending action subsystem in useContainerActions.ts — actionPending, actionPendingLifecycleModes, actionPendingLifecycleObserved, and the prune loop — was still entirely name-keyed. That meant:

1. You update docker-socket-proxy on Datavault (ID: abc123)
2. API call completes → actionPending.set("docker-socket-proxy", snapshot) — keyed by name
3. All four docker-socket-proxy rows match hasPendingContainerAction("docker-socket-proxy") → all grey out
4. Prune loop eventually clears it → others recover

Fix

Migrated the entire pending-action subsystem from name-keyed to action-key (container ID first, name fallback). For the replacement-update path where Docker swaps container IDs mid-update, a secondary identity key (server::name) is used so the prune loop can still find the replacement container without matching against a different host's same-named container.

This will ship in RC7. Please verify once it's out — same test: update one container from a same-named group in the Stacks View and confirm the others stay untouched.

[begunfx]

When another same-named group is available I will try to test for this. 👍

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

This has been addressed in the upcoming RC.

• Root cause: The UI was scoping pending update state by container name instead of a stable container identity (container ID). When you triggered an update on one portainer_agent, all containers sharing that image name would momentarily match the "updating" state.
• Fix: Update state is now scoped by the container's unique ID, so only the specific container you clicked will show the updating state (05c023fe)

The next RC will be out shortly — please test with your portainer_agent containers and let us know if the cross-contamination is gone.