fix(manage-server): upgrade.sh dies silently under set -e when app container is missing #26

Merged

amiryahaya merged 1 commit from fix/upgrade-sh-set-e-missing-app-container into main

2026-09-06 12:17:51 +02:00

amiryahaya commented

2026-09-06 12:17:43 +02:00

Owner

Sync of triton#986/triton#986 (fixed on the source-of-truth repo first,
per the standing installer-scripts-sync rule in triton's CLAUDE.md).

Summary

DB_STATUS/APP_STATUS=$(container_status ...) are bare command
substitutions in a plain assignment, not guarded inside a conditional.
container_status()'s 2>/dev/null only silences podman/docker inspect's stderr — it still exits non-zero when the container doesn't
exist. Under set -e, that kills the whole script immediately, silently,
before either intended message ever gets a chance to print:

the DB branch's own die "... has install.sh been run on this host?"
the app-container branch's comment: "report only ... must not block
recovery upgrades"

Found live while deploying manage-server/v1.2.0-rc.7 to a staging box: a
transient state where the app container had already been removed left
upgrade.sh --image ... exiting 125 with zero error output, requiring a
manual podman-compose up -d --no-deps manage-server to recover.

Fix

Add || true to both assignments, matching the file's own existing
convention for exactly this failure mode. Bumped SCRIPT_VERSION to
2026-09-06.1.

Test plan

bash -n manage-server/upgrade.sh — syntax OK
Byte-identical to triton's now-merged scripts/deploy/manage-server/upgrade.sh (except this repo's own path)

Sync of triton#986/triton#986 (fixed on the source-of-truth repo first, per the standing installer-scripts-sync rule in triton's CLAUDE.md). ## Summary `DB_STATUS`/`APP_STATUS=$(container_status ...)` are bare command substitutions in a plain assignment, not guarded inside a conditional. `container_status()`'s `2>/dev/null` only silences `podman`/`docker inspect`'s stderr — it still exits non-zero when the container doesn't exist. Under `set -e`, that kills the whole script immediately, silently, before either intended message ever gets a chance to print: - the DB branch's own `die "... has install.sh been run on this host?"` - the app-container branch's comment: "report only ... must not block recovery upgrades" Found live while deploying manage-server/v1.2.0-rc.7 to a staging box: a transient state where the app container had already been removed left `upgrade.sh --image ...` exiting 125 with zero error output, requiring a manual `podman-compose up -d --no-deps manage-server` to recover. ## Fix Add `|| true` to both assignments, matching the file's own existing convention for exactly this failure mode. Bumped `SCRIPT_VERSION` to `2026-09-06.1`. ## Test plan - [x] `bash -n manage-server/upgrade.sh` — syntax OK - [x] Byte-identical to triton's now-merged `scripts/deploy/manage-server/upgrade.sh` (except this repo's own path)

amiryahaya added 1 commit

2026-09-06 12:17:43 +02:00

fix(manage-server): upgrade.sh dies silently under set -e when app container is missing 60ad7a32d1

Sync of triton#986. DB_STATUS/APP_STATUS=$(container_status ...) are
bare command substitutions in a plain assignment — container_status()'s
2>/dev/null only silences podman/docker inspect's stderr, not its
non-zero exit when the container doesn't exist. Under set -e that kills
the whole script immediately, silently, before either intended message
(the DB branch's "has install.sh been run?" die, or the app-container
branch's documented "report only, must not block recovery" comment)
ever gets a chance to print.

Found live deploying manage-server/v1.2.0-rc.7. Add || true to both
assignments, matching the file's own existing convention for exactly
this failure mode. Bumped SCRIPT_VERSION to 2026-09-06.1.

amiryahaya merged commit fe67e54798 into main

2026-09-06 12:17:51 +02:00

amiryahaya referenced this pull request from a commit

2026-09-06 12:17:51 +02:00

fix(manage-server): upgrade.sh dies silently under set -e when app container is missing (#26)