fix(trigger-coolify-deploy): guard collateral-cancel status query

.github/actions/trigger-coolify-deploy/action.yml

@@ -311,8 +311,15 @@ runs:
           # slot per application, so /cancel on the phantom's uuid can tear down the
           # whole app's queue entry rather than just the targeted one. Detect that and
           # re-trigger once rather than failing the workflow on a cancel we didn't ask for.
+          set +e
           mine_status=$(curl -sf -H "Authorization: Bearer ${COOLIFY_API_TOKEN}" \
             "${COOLIFY_API_URL}/api/v1/deployments/${deployment_uuid}" | jq -r '.status // empty')
+          mine_query_status=$?
+          set -e
+          if [ "$mine_query_status" -ne 0 ]; then
+            echo "  WARNING: failed to query our own deployment ${deployment_uuid} (exit ${mine_query_status}) — assuming it was not collaterally cancelled." >&2
+            mine_status=""
+          fi
           if [ "$mine_status" = "cancelled-by-user" ] || [ "$mine_status" = "cancelled" ]; then
             echo "  Our own queued deployment (${deployment_uuid}) was collaterally cancelled while cancelling the native build — re-triggering..."
             raw=$(trigger_deploy)

CHANGELOG.md

@@ -52,6 +52,10 @@ All contributors (including maintainers) should update `CHANGELOG.md` when creat
 
 ## [Unreleased]
 
+### Fixed
+
+- **trigger-coolify-deploy**: the post-cancel check for a collaterally-cancelled own deployment (`mine_status=$(curl -sf ...)`) is now guarded with `set +e`/exit-status handling, matching the pattern already used by `cancel_phantom_builds()`'s own query. Previously, an unprotected `curl -sf` there could exit non-zero (e.g. exit 22 on a non-2xx response) under the script's top-level `set -euo pipefail` and hard-fail the whole deploy step instead of gracefully treating the query failure as "not collaterally cancelled".
+
 ## [4.3.1] - 2026-09-02