skip to content

An EAS Update at a 10% rollout is crashing for some users; how do you revert it, and what happens to devices that already downloaded it?

level: seniorimportance: should knowfreq 42%

answer

  1. no lowering, only reverting
  2. eas update:revert-update-rollout
  3. rollout group deleted, control republished
  4. empty branch means roll back to embedded
  5. devices move on their next check

basics

~20 s

Run eas update:revert-update-rollout: it deletes the rollout group and republishes the control update the other 90% run. Devices holding the bad update pick up that newer copy on their next check; if the branch had no earlier update, the revert publishes a roll back to embedded instead.

solid answer

~50 s

You cannot turn a rollout down to zero, because `eas update:edit` only accepts a higher percentage, so the tool for this is `eas update:revert-update-rollout`. It deletes the rollout update group and **republishes the control update**, the update that the 90% outside the rollout were already running. Because the republished copy is a new, newer update on the branch, the 10% of devices that downloaded the bad one find it on their next update check and move back to the old code; the other 90% just get a copy of what they already run. If the rollout was started on a branch with no earlier update, the revert publishes a **roll back to embedded** update instead, which tells clients to run the bundle inside their binary. The revert does not undo data the bad update wrote, so reverting is only safe if the old code can read it.

code

bash · 9 lines
bash
# See the rollout and its base (control) update
eas update:list --branch production

# Undo it: deletes the rollout group, republishes the control update
eas update:revert-update-rollout --branch production --message "Revert share fix"

# Later: ship the corrected code as a new rollout
eas update --channel production --environment production \
  --message "Share fix, take two" --rollout-percentage 10

go deeper

for a junior

Know that a bad rollout is undone with eas update:revert-update-rollout, not by editing the percentage.

for a middle

Explain what the revert publishes: the control update republished, or a roll back to embedded when the branch was empty.

for a senior

Describe what the 10% experience after the revert, why they move only on their next check, and when persisted data makes a revert unsafe.

for a principal

Set the team rule for revert versus fix forward and the evidence required before either, owning the trade between exposure time and data risk.

## The situation You published an **EAS Update** with `--rollout-percentage 10`. Crash reports climb for the devices that got it. The rollout exists exactly for this moment, but the first instinct, lowering the percentage, is not available: `eas update:edit` rejects any value below the current one. Undoing a per-update rollout is always a **revert**. ## What the revert command does ```bash eas update:revert-update-rollout --channel production --message "Revert share fix" ``` It accepts `--channel`, `--branch` or `--group` to find the rollout, an optional `--message`, and `--private-key-path` when updates are code-signed. Then one of two things happens: | Branch state when the rollout started | What the revert publishes | |---|---| | An earlier update existed (the **control update**) | Deletes the rollout group and **republishes the control update group** | | The branch was empty | Deletes the rollout group and publishes a **roll back to embedded** update | In interactive mode the CLI asks for confirmation, naming the group it will delete and the one it will republish. ## What happens on devices The revert happens on the server; devices learn about it the way they learn about any update, when **expo-updates** next checks. 1. The **90% outside the rollout** were running the control update. The republished copy is a new update with the same code, so switching to it changes nothing they can see. 2. The **10% that already downloaded the bad update** find the republished control update on their next check. By default that check happens at a cold launch and the downloaded update runs on the following one, so these users may see the bad code once or twice more. 3. Devices in the 10% that **never checked** during the rollout simply receive the republished control update. 4. With a **roll back to embedded** directive, clients switch to the bundle in their binary; `checkForUpdateAsync()` reports it as `isRollBackToEmbedded`. If the bad update crashes before its first render, expo-updates' own error recovery may already have moved those devices off it; that on-device mechanism is separate from the revert. ## What a revert cannot undo - **Persisted data.** If the bad update migrated storage, the older code must be able to read the new shape; otherwise the revert trades one crash for another. - **Native state.** An update never changed native code, so there is nothing native to revert. - **Time on bad code.** Devices move only when they check, so a revert shortens exposure rather than ending it instantly. ## Confirming the recovery After the revert, verify rather than assume. The rolled-out group disappears from `eas update:list`, and the republished control update appears as the newest group on the branch. On a test device that had received the bad update, cold-launch twice and read `Updates.updateId` (or a diagnostics screen built on it): it should now report the republished update's ID. In the dashboard, failed installs for the bad update should stop growing as devices check in. If some devices keep crashing before they can check, those are the ones expo-updates' on-device recovery has to rescue; the server side has done all it can. It also helps to write the revert down: which group was reverted, why, and which fix will replace it. The update list then reads as an honest history, which matters the next time someone wonders why a republished update exists. ## Revert or fix forward | Choose | When | |---|---| | Revert now | The cause is unclear, or the fix needs more than a few minutes of testing | | Fix forward | The bad update wrote data the old code cannot read, or the fix is small and verified | Fixing forward still starts with a revert or a finish here, because EAS refuses a new publish for that runtime version while the rollout is open. A common sequence is: revert, verify the 10% recover, then publish the fix as a fresh rollout.

  • Why is the revert implemented as a republish rather than just deleting the bad update?
    Devices that downloaded the bad update keep it locally; deleting it on the server gives them nothing newer to move to. Republishing the control update creates a newer update on the branch, which clients select on their next check, so every device converges on the previous code.
  • What would you check before reverting when the bad update changed how data is stored?
    Whether the control update's code can read what the bad update wrote. If it cannot, reverting swaps one crash for another, and a small fix-forward that reads both formats is the safer path. Testing that on a device that ran the bad update is the only reliable check.

saying these in an interview costs you the question

  • Tries to lower the rollout to 0% with eas update:edit
  • Believes the revert removes the bad update from devices instantly
  • Assumes reverting also undoes data the bad update migrated
  • Publishes a hotfix without ending the open rollout first
  • Thinks the other 90% need to download different code after a revert