Updating a container no longer works rc.8

[begunfx]

Drydock version

1.5.0-rc.8

What happened?

This is repeatable. If you try to update a container via the Updates Available widget on the dashboard, the entire dashboard reloads, and no updating events occur. However, if I update a container from the container screen the containers do update as expected.

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

[begunfx]

Correction: Updates don't seem to be working at all. I tried updating a container from the container view, and it goes into an updating state but the container never updates. My original assumption was they were updating from the container view, but I must have missed that the container I just updated was still there afterwards...

[begunfx]

Getting the following error when I try to update my container:

Error updating container 5798db91762a93500d6e0f445a2976ffde8743261504a672efb8656ae4420c17 (Request failed with status code 413)
4
[13:00:29.322]
error
agent-client.mediavault
Error running remote trigger: Request failed with status code 413
5
[13:00:18.687]
debug
agent-client.mediavault
Running remote trigger docker.mediavault (container={"id":"5798db91762a93500d6e0f445a2976ffde8743261504a672efb8656ae4420c17","name":"calibre","status":"running","watcher":"mediavault","displayName":"calibre","displayIcon":"mdi:docker","image":{"id":"sha256:ea98d28d2408b8dcef1957ac737d907048cd6ba1e5955d591829f349b644ab9f","registry":{"name":"ghcr.public","url":"https://ghcr.io/v2"},"name":"linuxserver/calibre","tag":{"value":"latest","semver":false,"tagPrecision":"floating"},"digest":{"watch":true,"repo":"sha256:4004e191a4a0fa59ce887996f3260c254bc...)

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

Root-caused and fixed. Thanks for the detailed logs — the Request failed with status code 413 line was the key.

What was happening

When you clicked Update on a container on mediavault, the controller (datavault) tried to execute the docker.mediavault trigger against your remote agent. The controller POSTs the container object to the agent over HTTP, and the agent's express body parser is capped at 256kb (app/agent/api/index.ts:120, added in a45d533b as part of v1.5.0 DoS hardening).

The problem: the controller was posting the entire Container object — id, name, watcher, displayName/displayIcon, full image block (registry, tag, digest watch config), full result block (including releaseNotes.body), details.env, details.labels, observability fields, etc. Over the v1.5 RC cycle that payload quietly grew, and for a container like linuxserver/calibre:latest — which ships a long release-notes changelog plus a normal-sized env array — the serialized payload crossed 256kb. Express replies 413 before the agent's handler even runs, so the update never starts. The dashboard reload you first noticed was the UI reacting to the failed POST.

Why this was avoidable

For docker / dockercompose update triggers the agent's handler (app/api/trigger.ts:172-186) only reads two fields out of the payload:

• container.id — to look up the agent's own store record (the agent drives the update off its own state, not the controller's snapshot).
• container.name — used by the rollback-container guard (isRollbackContainer).

Everything else in the payload was dead weight. For notification triggers (smtp, slack, etc.) the full container is legitimately needed because the agent renders templates against it, so those still post the full object.

Fix

AgentClient.runRemoteTrigger now posts { id, name } for docker / dockercompose triggers and keeps posting the full container for notification trigger types. The axios call shrinks from ~200–300kb to ~60 bytes, well under any reasonable body cap.

Regression tests assert that a docker update trigger with a 300kb release-notes body posts only { id, name } and that an smtp notification trigger keeps posting the full container.

What this unblocks

• Dashboard "Update" widget and container-view Update button both start working again on any container large enough to have tripped the 256kb cap.
• "Update All" over remote agents works again.
• update-applied / update-failed notifications should come through normally once the update actually runs (so the Updated Successfully notification not received consistently #290 verification can also proceed on the next RC).

Workaround on rc.8

There isn't a clean one from the UI side — the bloat is generated server-side. If you urgently need an update on a large container, triggering it via the agent's API directly (skipping the controller's trigger handler) bypasses the 413 path, but that's not practical. Easiest path is to wait for the next RC.

Fix ships in the next RC. Leaving open for your verification once that's out.

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

Reopening — closed this without your verification.

The 413 was the controller→agent POST carrying the full container payload past the agent's default express body-parser limit. The fix raises the agent-side limit and trims the serialized payload on the controller side. Ships in v1.5.0-rc.9, out shortly.

Once you're on rc.9, please try updating a container on mediavault from the container view and confirm the update goes through (no Request failed with status code 413 in the agent-client.mediavault log). Leaving open until you sign off.