Release channel OTA always from default channel, but not the release-channel set during build

🐛 Bug Report

Summary of Issue

I build my app with expo build:ios --release-channel prod-v1. But expo publish --release-channel prod-v1 doesn’t push the OTA update to that build. Instead, I have to expo publish (with the default channel) to push the OTA update to that build.

Environment - output of expo diagnostics & the platform(s) you’re targeting

  Expo CLI 3.27.7 environment info:
    System:
      OS: macOS 10.15.6
      Shell: 5.7.1 - /bin/zsh
    Binaries:
      Node: 14.11.0 - /usr/local/bin/node
      Yarn: 1.22.5 - /usr/local/bin/yarn
      npm: 6.14.8 - /usr/local/bin/npm
    Managers:
      CocoaPods: 1.9.3 - /usr/local/bin/pod
    SDKs:
      iOS SDK:
        Platforms: iOS 14.0, DriverKit 19.0, macOS 10.15, tvOS 14.0, watchOS 7.0
    IDEs:
      Android Studio: 4.0 AI-193.6911.18.40.6626763
      Xcode: 12.0/12A7209 - /usr/bin/xcodebuild
    npmPackages:
      expo: ^39.0.0 => 39.0.2
      react: 16.13.1 => 16.13.1
      react-native: https://github.com/expo/react-native/archive/sdk-39.0.0.tar.gz => 0.63.2
    npmGlobalPackages:
      expo-cli: 3.27.7
    Expo Workflow: managed

Reproducible Demo

Steps to Reproduce

1. expo build:ios --release-channel prod-v1 a project and upload this build to TestFlight. (I also briefly tested Android build and found the same problem)
2. Update any JS code in the project.
3. expo publish --release-channel prod-v1

Expected Behavior vs Actual Behavior

Expected Behavior: The JS updates should be reflected in the build after relaunching twice (my fallbackToCacheTimeout is 0). Moreover, expo publish should not affect this build.

Actual Behavior: No matter how many times I opened the app, stayed in the app for > 30 seconds, and relaunched the app, the app did not receive the new update. Instead, when I do expo publish, the update shows up in the build (even though this should be publishing to the default channel, not the prod-v1 channel).

[Aryk]

We’ll most likely be able to look into this starting next Wednesday. To our knowledge, this issue impacts SDK 39 in all environments including the app store development client and standalone apps for both Android and iOS. Until a fix goes out we recommend using SDK 38 if you rely on release channels.

Which I think 90% of people with Expo apps in production do 😉

Does it make sense as a practice moving forward to add high-impact bugs like this that affect all users to the SDK Release page so that others know what awaits them. Probably there are another 3-4 high-impact obvious things that may be broken that should also be there besides this one.

Yes, obviously one can peruse through the github issues…but without literally clicking on each one and reading all of the comments…it’s not clear if its been a) identified by Expo and b) will be fixed soon.

[connor-odoherty]

To piggyback what Aryk said, it’s concerning that:

a) There is very little visibility into these high-impact breakages and b) There isn’t any sort of testing in place to protect against such a major breakage

At the very least, updating the “Upgrade to 39” blog post with a list of known issues, warning users before they commit time to upgrading and subsequently debugging the broken upgrade, would have have been appreciated. There have been multiple app breaking changes that are only discovered upon digging through GitHub issues, which is unacceptable when the only way to know of these high-impact issues is to experience them firsthand after an upgrade.

Release channels are critical to any organization with an Expo app currently in production. It worries me that both this, and the broken “from dead state” push notification handler made it out into a release (with the latter taking a full release to be patched).

Is there a plan to improve the way these releases are managed? As users, should SOP be waiting a month for the release to stabilize before upgrading? Normally, this would seem like best practice, but it isn’t always viable (like when a new version of iOS is released, or when needing a fix for issues from a previous release).

I apologize for all the negativity, especially considering how great Expo has been for our organization as a whole. You all have been great in support so far, and we appreciate the hard work, I assume we can chalk this up to growing pains.