Tapping several containers now updates several containers
Get the update notification, tap four containers, and one of them ran. The other three answered
⚠️ An update is already running...
and were then thrown away. Nothing remembered them, so you had to come back after each update finished and tap the next one again — and nothing told you which ones had never run.
They queue now. Each tap answers with its position and they work off one after the other.
The lock stays. Two updates recreating containers at the same time is exactly what v1.23.1 was added to prevent, and it is still prevented. What was wrong was what happened to the rejected taps: nothing at all.
It is re-taken per entry rather than held across the whole queue. Holding it for five containers would lock out the scheduler, "update all" and a queued self-update for ten minutes; re-acquiring per entry keeps the concurrency guard while letting other work in between.
A failure carries on to the next container — unless they are in the same group. Group order exists because those containers depend on each other, and updating the next one against a head that just failed is how an app ends up talking to a database that rolled back. The skipped ones are named, so you know what to re-tap after fixing the one that failed. Containers outside that group are unaffected.
And a pending self-update stops the drain and says what will not run. The queue lives in memory, and a self-update restarts the process, so carrying on would drop the rest without a word — which is the failure mode this whole area has spent a week fixing. It is bounded at ten, repeat taps are recognised rather than queued twice, and a full queue is an honest refusal rather than a silent drop.
Nothing to do on upgrade.