[expo-updates] `isEmergencyLaunch` — what factors cause this, how common, how to handle?

[tsheaff]

Please provide the following:

1. SDK Version: expo-updates@0.14.6
2. Platforms(Android/iOS/web/all): iOS and Android
3. Add the appropriate “Tag” based on what Expo library you have a question on.

Hello. I’m currently layering in expo-updates to my app’s workflow, using the new EAS Updates system. I see in the docs for expo-updates that we must handle the Updates.isEmergencyLaunch boolean. I have a local DB (realm) that has a sequential schema migration system, and it’s not really well-suited for going backwards, so this is making me wonder how bad it could get if that isEmergencyLaunch flag came back true. In the worst case, it could corrupt the data in the DB, and crash instantly / require a fresh install. The docs say this, but nothing further:

expo-updates does its very best to always launch monotonically newer versions of your app so you don't need to worry about backwards compatibility when you put out an update. In very rare cases, it's possible that expo-updates may need to fall back to the update that's embedded in the app binary, even after newer updates have been downloaded and run (an "emergency launch"). This boolean will be true if the app is launching under this fallback mechanism and false otherwise. If you are concerned about backwards compatibility of future updates to your app, you can use this constant to provide special behavior for this rare case.

Does anyone on the expo team know under what circumstances this would be necessary? How common is this? If I ignore this case, how much technical risk am I creating? It’s a bit surprising that the expo-updates system can’t simply make a hard guarantee that it never reverts the code and only moves forward monotonically on versions.

[tsheaff]

Does anyone have any insights here? It seems like a very critical thing to handle correctly. Surprised there’s not more info about what circumstances we should expect this to occur.