Retry the Play publish with the opposite review flag

[patrickrb]

Why

The dev -> staging promotion (#810) ran green but no internal release appeared on Play. The Android run's "Publish AAB to Play" step is continue-on-error, so the failure only showed up as an annotation:

Uploading ft8af/app/build/outputs/bundle/release/app-release.aab
Successfully uploaded 1 artifacts
Committing the Edit
##[error]Changes cannot be sent for review automatically. Please set the query
parameter changesNotSentForReview to true. Once committed, the changes in this
edit can be sent for review from the Google Play Console UI.

The AAB uploaded fine; the edit was never committed, so android-dev.1231 / 0.150.0-dev.1231 never reached the internal track. The Sept 8 staging build (android-dev.1225) committed cleanly, so the app's Play Console review state flipped between the two — consistent with the app now having review-gated changes pending.

What

changesNotSentForReview is not really ours to choose. Google's edit commit demands one specific value and rejects the other, and which one it wants depends on Console state that changes outside CI:

Play Console state	commit behavior
normal reviewed app	auto-sends for review; rejects the flag ("...must not be set")
review-gated changes pending	refuses to auto-send; requires the flag true

We have been burned in both directions — false broke android-dev.1231 today, true broke android-dev.1026 once the app went back to normal — and the step comment had turned into a note about which way to hand-flip it next. So instead of flipping the literal again:

• keep false (the normal path) as the first attempt;
• add a retry step that re-runs the upload with changesNotSentForReview: true only when the first commit failed. The failed edit is never committed, so its versionCode stays unused and re-uploading the same AAB is safe;
• when the retry is what succeeded, emit a warning: the release is on the track but was not sent for review, so someone has to submit the pending changes in the Play Console before testers get the build;
• the existing failure warning now only fires when the retry also failed, and the run summary's Play track: ... (publish: ...) line reflects the retry outcome.

Testing

Validated that the workflow still parses and that the four steps' if conditions and flag values are wired as intended.

No unit test accompanies this — the change is entirely GitHub Actions workflow wiring, which the repo's JVM test suite cannot reach. It gets exercised for real by the next dev -> staging promotion.

Note

This unblocks future staging builds. The current 0.150.0 internal build still has to be re-cut (the next promotion run will do it with a fresh run number / versionCode), and if the retry path is what fires, the Play Console will need a manual "send for review".

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ht2BB4TWtkmC5EW5GsPXEM

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 42.40%. Comparing base (caadc95) to head (c98505e).

Additional details and impacted files

@@            Coverage Diff            @@
##                dev     #811   +/-   ##
=========================================
  Coverage     42.40%   42.40%           
  Complexity      228      228           
=========================================
  Files           270      270           
  Lines         32450    32450           
  Branches       3735     3735           
=========================================
  Hits          13761    13761           
  Misses        18413    18413           
  Partials        276      276           

Flag	Coverage Δ
android	17.21% <ø> (ø)
native	9.93% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.