[CI] Surface and fix recurrent iOS Sentry size-analysis upload failures

[Beamanator]

🤖 Posted by Codex, an AI coding agent acting for @Beamanator.

Summary

Upload iOS build to Sentry for size analysis is failing almost continuously, but the deployment workflow remains green and the real sentry-cli error is discarded.

Evidence

• Linked failure: production deploy run #6003 (2026-08-20).
• The iOS artifact download succeeds: gh release download "9.4.56-3-staging" --pattern "Expensify.ipa" completed successfully.
• The next step, npx sentry-cli build upload "Expensify.ipa" --org expensify --project app --build-configuration Release --log-level info, exits with code 1.
• Among the 33 production deploy runs after this upload moved into deploy (2026-06-26 through 2026-08-20), 31 have the same Upload to Sentry for size analysis — Process completed with exit code 1 annotation (~94%). Only two runs completed without that annotation.
• No open App issue matches this failure. Related setup/migration work is closed: [Due for payment 2026-07-03] Set up Sentry release size analysis #82850, [HOLD][No QA] Set up Sentry release size analysis #82937, [No QA] ci: Add Sentry build size analysis #82952, [No QA] Move sentry size analysis upload to deploy step #94039, and [Due for payment 2026-07-02] Bundle Size Analysis links in deploy comments are broken #94382.

Why diagnosis is currently impossible

The composite action captures the CLI output in a command substitution:

OUTPUT=$(npx sentry-cli build upload "$ASSET" ... 2>&1)
echo "$OUTPUT"

GitHub runs Bash with -e. When sentry-cli exits non-zero, the assignment itself exits non-zero, so the step stops before echo "$OUTPUT". Its stderr is therefore captured and lost.

Both the composite upload step and the workflow job use continue-on-error, so the deploy stays successful while GitHub records only the unhelpful exit-code annotation. We can prove that sentry-cli is the failing command, but cannot determine whether the immediate cause is Sentry authentication, an API/quota error, or invalid build metadata from historical logs.

Proposed fix

1. Preserve and print the CLI output before failing:

set +e
OUTPUT=$(bunx sentry-cli build upload "$ASSET" \
  --org expensify \
  --project app \
  --build-configuration Release \
  --log-level info 2>&1)
EXIT_CODE=$?
set -e
printf '%s\n' "$OUTPUT"

if (( EXIT_CODE != 0 )); then
  echo "::error::Sentry size-analysis upload failed (exit $EXIT_CODE)"
  exit "$EXIT_CODE"
fi

2. Keep the outer job non-blocking only if that is intentional, but retain the emitted diagnostic in the action log.
3. Add explicit logging around the release-artifact download so an absent/invalid IPA is distinguishable from a Sentry upload failure.
4. Re-run a production upload after the observability fix and use the retained sentry-cli output to address the actual service/configuration cause.

Acceptance criteria

• A failed upload logs the complete sentry-cli diagnostic.
• The workflow clearly distinguishes artifact-download failures from Sentry-upload failures.
• The next production run either uploads successfully or provides enough evidence to fix the remaining root cause.

[Beamanator]

@MelvinBot investigate the issue and proposed fix

[MelvinBot]

Issue Analysis

The diagnosis is correct. The sentry-cli output is lost because of a classic set -e gotcha, not because sentry-cli writes nothing. The proposed fix is the right approach with two corrections (keep npx, not bunx; and item #3 is already largely handled).

Root cause: GitHub runs shell: bash as bash --noprofile --norc -eo pipefail {0}, so set -e is on. In uploadSentrySizeAnalysis/action.yml:64 the step is:

OUTPUT=$(npx sentry-cli build upload "$ASSET" ... 2>&1)
echo "$OUTPUT"

An assignment whose value comes from a command substitution takes the substitution's exit status, so when sentry-cli exits 1 the assignment exits 1 and set -e aborts the step before echo "$OUTPUT" runs. The captured stderr never prints; all that survives is the Process completed with exit code 1 annotation. continue-on-error: true on both the step and the job then keeps the deploy green, so the failure is invisible except as noise. All of this matches the issue exactly.

Recommended fix — apply the set +e / capture-exit / print pattern from the proposal, with these adjustments:

set +e
OUTPUT=$(npx sentry-cli build upload "$ASSET" \
  --org expensify --project app --build-configuration Release --log-level info 2>&1)
EXIT_CODE=$?
set -e
printf '%s\n' "$OUTPUT"

SENTRY_URL=$(printf '%s' "$OUTPUT" | grep -oE 'https://expensify\.sentry\.io/[^ )"}]+' | head -1)
if [ "$EXIT_CODE" -ne 0 ]; then
  echo "::warning::${PLATFORM} Sentry size-analysis upload failed (exit $EXIT_CODE) — see log above"
  exit 0
elif [ -n "$SENTRY_URL" ]; then
  echo "::notice::${PLATFORM} Sentry size analysis: $SENTRY_URL"
  echo "SENTRY_URL=$SENTRY_URL" >> "$GITHUB_OUTPUT"
fi

Why these adjustments to the proposal

1. Keep npx, not bunx. The proposal's snippet silently switches npx → bunx. This composite sets up Node via setupNode (npm), not bun, so bunx would introduce a new failure. Change only the error handling, not the runner.

2. ::warning:: + exit 0 instead of ::error:: + exit $EXIT_CODE. Both the step and the job already carry continue-on-error: true, so the exit code can't block the deploy either way — but exiting non-zero keeps emitting the red run-level annotation that motivated this issue. Emitting a warning and exiting 0 surfaces the full CLI diagnostic and removes the persistent red noise. If you'd rather keep it visibly failing, exit "$EXIT_CODE" is fine — the diagnostic now prints regardless.

3. Proposal item Add Expensify eslint #3 (distinguish download vs upload failures) is already handled. The re-promotion path already guards the download with [ -s "$ASSET" ] || { echo "::error::Failed to obtain..."; exit 1; }, and the upload step is gated by if: hashFiles(inputs.asset-name) != ''. So a missing/empty IPA fails at the download step and skips the upload — it can't masquerade as a Sentry failure today. The only small gap is the cherry-pick path (download-artifact with continue-on-error): if that produced no file the upload is silently skipped with no note. An optional else branch on the hashFiles guard logging "no binary found, skipping upload" would close that.

4. The actual service-level cause still can't be known from code — and that's the point. This fix is observability; it makes the next production run print the real sentry-cli error. Two data points worth noting up front: the issue confirms gh release download succeeds, which needs GH_TOKEN — so the caller's step-level env (including SENTRY_AUTH_TOKEN) is reaching the composite's steps, making a plain auth failure unlikely. Combined with the action's own doc string ("empty if upload failed or quota exhausted"), Sentry size-analysis quota exhaustion is the leading hypothesis for the ~94% rate. Confirm from the retained output once merged.

Confidence: High on the root cause of the lost output and the fix. The underlying reason sentry-cli itself exits 1 is unverifiable from code alone (by design — this issue exists to surface it).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

---

view run

[Beamanator]

will look into this more this week

[Beamanator]

same