expo-updates runtime and EAS Update service: how should rollback recovery be verified on real devices?

Answer the Exact Questions First

• Q1 – Source of Truth for Rollback Confirmation: Logging Updates.updateId (or the full bundleUrl) at app launch is the only per‑device source that guarantees the bundle that actually ran. The EAS dashboard only shows the most recent update that the server pushed; it does not expose per‑device state, so it cannot confirm that every device applied the rollback.
• Q2 – Behavior on a Wrongly Signed Rollback: With code signing enabled, a signature mismatch causes the runtime to reject the update and silently fall back to the embedded bundle. No JavaScript exception is thrown; the native console logs a warning and Updates.getLastUpdateMetadataAsync() will return the embedded bundle’s metadata.
• Q3 – Forcing a Quick Check‑Cycle: There is no OS‑level override, but you can set checkAutomatically to ON_ERROR_OR_NEXT_ROUTINE and minimumCacheDuration to 0 to allow a check on every launch. The most deterministic method is to call Updates.checkForUpdateAsync() immediately after repointing the channel (or after a manual app restart). This forces the runtime to evaluate the rollback bundle before the next scheduled cycle.

Confirmed Facts vs. Likely Explanations

Confirmed Facts (from Expo’s runtime docs and EAS API behavior):

• The runtime only accepts a signed update if the signature matches the key bundle shipped with the binary.
• When a signed update fails, the runtime silently loads the embedded bundle; no JS error is propagated.
• Runtime telemetry (Updates.updateId and bundleUrl) captured at launch is the only reliable per‑device indicator of the bundle in use.
• Setting minimumCacheDuration to 0 and checkAutomatically to ON_ERROR_OR_NEXT_ROUTINE removes the delay between launches, but the OS may still throttle background fetches.
• There is no built‑in API to force a check‑cycle immediately after a channel change; the recommended approach is to trigger Updates.checkForUpdateAsync() from JavaScript.

Likely Explanations (based on typical deployment patterns):

• Telemetry logs sent to a custom analytics endpoint give you a deterministic audit trail of which devices have applied the rollback.
• If you rely solely on the EAS dashboard, you risk missing devices that still use the embedded bundle because the check cycle hasn’t fired yet.
• For large fleets, you might batch the checkForUpdateAsync() calls to avoid network spikes.

Steps to Verify Rollback Recovery on Real Devices

1. Prepare a Verification Endpoint
   • Deploy a lightweight HTTPS endpoint that accepts POST requests containing deviceId, updateId, and bundleUrl.
   • Store the data in a database or analytics platform for later cross‑reference.
2. Instrument the App
   • In App.js, add the following snippet to run on every launch:

     import { Updates } from 'expo-updates';
     
     async function reportUpdate() {
       const metadata = await Updates.getLastUpdateMetadataAsync();
       const payload = {
         deviceId: await DeviceInfo.getUniqueIdAsync(),
         updateId: metadata?.updateId ?? 'embedded',
         bundleUrl: metadata?.bundleUrl ?? 'embedded',
       };
       await fetch('https://your‑endpoint.example.com/report', {
         method: 'POST',
         headers: { 'Content-Type': 'application/json' },
         body: JSON.stringify(payload),
       });
     }
     
     reportUpdate();
     

   • Ensure the call runs before any critical UI logic so that the telemetry reflects the bundle actually executed.
3. Repoint the Channel
   • Update the channel mapping in the EAS dashboard or via the CLI to point to the older branch/rollback bundle.
   • Optionally, publish the rollback bundle as a new release if you want a unique updateId for verification.
4. Trigger a Forced Check (Optional but Recommended)
   • After repointing, call Updates.checkForUpdateAsync() immediately in the app (e.g., on a splash screen or a dedicated “Check for updates” button).
   • If a new update is returned, call Updates.fetchUpdateAsync() to apply it before the user sees the app.
5. Collect and Cross‑Reference Data
   • Query the EAS API for the channel’s currentUpdate field to confirm the intended rollback updateId.
   • Download the telemetry logs from your endpoint and filter for the rollback updateId.
   • Any device that reports a different updateId (or “embedded”) is still on the bad bundle or has not yet launched.
6. Monitor Crash Reports
   • In your crash‑reporting tool, look for crash reports that reference the old bundle’s hash or updateId. This indicates a device that never launched after the rollback.

What If You Lack a Telemetry Endpoint?

Without a custom endpoint, you can still use the Updates.getLastUpdateMetadataAsync() value in a Sentry event or similar, but you’ll need to ensure those events are reliably delivered and stored. If that’s not feasible, consider adding a lightweight backend to capture the data for audit purposes.

Final Checklist

• Telemetry endpoint deployed and verified.
• App instrumented to log updateId and bundleUrl at launch.
• Channel repointed to the rollback bundle.
• Forced check performed (if desired).
• Telemetry cross‑referenced with EAS channel data.
• Crash reports reviewed for old bundle signatures.

When all devices report the rollback updateId, you can confidently say the fleet has recovered. If any device still reports the old updateId or “embedded”, target those devices with a forced check or a user‑facing prompt to restart the app.