Repository navigation
Fail update when the platform rejects the container change - #15
Merged
Merged
Conversation
`container-groups update` exited 0 when the API accepted a container change and then dropped the new version: the group stayed on its old image, the write-verification diff printed one `warning:` line, and the platform's reason (`current_state.description`, e.g. "Version 2: Manifest Not Found") was never shown. A private Docker Hub image sent without its registry credentials fails exactly this way. After the settle, `applyPatch` now treats a container change that did not land as an error: exit 6 (`invalid_input`), stdout empty, the API's reason in the message. Two signals, either enough: a container field the patch named (image, command, cpu, memory, GPU classes, storage, an environment variable) stayed exactly where it was, or the write left a new "Version N: <reason>" for an N above the running version. Only a new report counts, since the API keeps it on the group through later writes. When the patch changed the image without `container.registry_authentication`, the hint reuses create --from's credential advice, keyed on the failure rather than on the registry. Verified live on a busybox CPU group (running and stopped) with a nonexistent tag; the live suite's TestGroupLifecycle gains the same step. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…ejected-5cc4ec # Conflicts: # CHANGELOG.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When you run
container-groups updatewith a new image, the API accepts the change at once and then checks it beforeany instance runs it. If the registry doesn't serve that image, for example a tag that doesn't exist or a private image
sent without its registry credentials, the platform drops the new version and the group keeps running the old one. The
CLI waited for the change to settle, but it only printed one
warning:line on stderr, exited 0, and never showed theplatform's reason, so a failed update looked like a success. Now
updatetreats a container change that didn't landas an error: it exits 6 with the platform's reason, and when the image changed without credentials, the hint says a
private image needs them sent again.
Changes
internal/cli/intentdiff.go,groups.go: after the settle,updatefails when a container change didn't land.Either of two signals is enough: a container field the patch named (image, command, CPU, memory, GPU classes,
storage, an environment variable) stayed exactly where it was, or the write left a new
Version N: <reason>description for an
Nabove the running version. Only a new report counts, because the API keeps the old one on thegroup through later writes. The error is exit 6, kind
invalid_input, with empty stdout and a message such asthe API did not apply the container change to my-app: Version 2: Manifest Not Found.container.registry_authentication, the hint reusescreate --from'scredential advice. It is keyed on the failure, not on the registry, so it applies to Docker Hub too.
internal/cli/containerrejection_test.go: unit and harness tests for both signals, the stale-description case andthe hint.
internal/livetest/provision_test.go:TestGroupLifecyclegains an update to a tag that doesn't exist.docs/guide.md,docs/commands.md,docs/notes.md, the validation table inAGENTS.md, and a### FixedCHANGELOG entry.
Contract change
container-groups updatenow exits 6 (kindinvalid_input, stdout empty) in a case where it used to exit 0 and printthe settled group. No new exit code or error kind; the guide's exit-code and kind tables mention the new case.
Checklist
just cipasses (formatting, lint, and the offline tests): run locally on Windows with Go 1.27.3, after mergingmain.docs/(and the README, if install or getting started changed) andCHANGELOG.md(under Unreleased) reflect thechange.
hand on a busybox CPU group, both running and stopped, with a tag that doesn't exist. The private-image case
wasn't reproduced live; its message comes from an earlier failure. There's no record yet of
just test-livebeing run with the new
TestGroupLifecyclestep.🤖 Generated with Claude Code