Critical bug in Expo Updates in bare workflow has caused unreachable builds for OTA

[shamilovtim]

Summary

The Expo Updates CLI's inference is causing a state where users cannot push OTA updates.

Given that the user has control over EXUpdatesSDKVersion the user can release builds with EXUpdatesSDKVersion that does not match what the Expo Updates CLI expects. When the user tries to push to this release the Expo Updates CLI inference prevents that push from occurring instead directing it to the EXUpdatesSDKVersion it inferred. There is no -force flag and seemingly no setting to push an SDK version that the user knows better than the CLI.

Here's an example of this behavior in action. The user publishes a build with EXUpdatesSDKVersion: 45.0.1. The user needs to push an OTA to this 45.0.1 build. When the user tries to do this he gets the following behavior:

After the OTA visit the link of where the CLI said the bundle was published and you should see the CLI published to 45.0.0 despite the user trying to send the OTA to his active build in production, the SDK version of 45.0.1 is now unreachable. The CLI thinks `45.0.1` cannot possibly be a valid SDK version and does not allow the user to OTA to this SDK version.

I've now stumbled on this behavior twice. I think there needs to be a --force flag for expo:publish. Also, if patch versions aren't valid inside of EXUpdatesSDKVersion then make it an integer so its 45 rather than major.minor.patch.

I assume this same problem exists on Android as well.

Managed or bare workflow? If you have ios/ or android/ directories in your project, the answer is bare!

bare

What platform(s) does this occur on?

iOS

SDK Version (managed workflow only)

No response

Environment

  expo-env-info 1.0.3 environment info:
    System:
      OS: macOS 12.3.1
      Shell: 3.4.1 - /usr/local/bin/fish
    Binaries:
      Node: 16.4.2 - ~/.nvm/versions/node/v16.4.2/bin/node
      Yarn: 1.22.18 - ~/.yarn/bin/yarn
      npm: 8.7.0 - ~/.nvm/versions/node/v16.4.2/bin/npm
      Watchman: 2022.03.21.00 - /usr/local/bin/watchman
    Managers:
      CocoaPods: 1.11.3 - /Users/admin/.rvm/gems/ruby-2.7.4/bin/pod
    SDKs:
      iOS SDK:
        Platforms: DriverKit 21.4, iOS 15.4, macOS 12.3, tvOS 15.4, watchOS 8.5
      Android SDK:
        API Levels: 26, 27, 28, 29, 30, 31
        Build Tools: 27.0.3, 28.0.0, 28.0.3, 29.0.2, 29.0.3, 30.0.0, 30.0.2, 30.0.3
        System Images: android-26 | Google APIs Intel x86 Atom, android-28 | Google Play Intel x86 Atom, android-29 | Google APIs Intel x86 Atom, android-29 | Google Play Intel x86 Atom, android-30 | Google Play Intel x86 Atom
    IDEs:
      Xcode: 13.3.1/13E500a - /usr/bin/xcodebuild
    npmPackages:
      babel-preset-expo: ~9.1.0 => 9.1.0
      expo: 45.0.1 => 45.0.1
      react: 17.0.2 => 17.0.2
      react-native: 0.68.1 => 0.68.1
    npmGlobalPackages:
      expo-cli: 5.4.3
    Expo Workflow: bare

Reproducible demo

N/A

[expo-bot]

Thank you for filing this issue! This comment acknowledges we believe this may be a bug and there’s enough information to investigate it. However, we can’t promise any sort of timeline for resolution. We prioritize issues based on severity, breadth of impact, and alignment with our roadmap. If you’d like to help move it more quickly, you can continue to investigate it more deeply and/or you can open a pull request that fixes the cause.

[brentvatne]

did you set EXUpdatesSDKVersion manually 45.0.1? if so, i'd suggest changing it back to 45.0.0. that said, we should look into improving this experience

[brentvatne]

an aside - if you'd like to have separate builds that you can target for a single sdk version, i'd suggest using runtime versions: https://docs.expo.dev/eas-update/runtime-versions/

[shamilovtim]

an aside - if you'd like to have separate builds that you can target for a single sdk version, i'd suggest using runtime versions: https://docs.expo.dev/eas-update/runtime-versions/

Yeah I actually published an SDK 45 build with that field set to "43.0.0." As in, I totally forgot to increment it. Then when I go to try to codepush to "43.0.0" it won't let me due to the CLI not allowing me to force push an OTA to there. Completely agree I need to switch to the runtime version workflow to sidestep this issue entirely.

[shamilovtim]

did you set EXUpdatesSDKVersion manually 45.0.1? if so, i'd suggest changing it back to 45.0.0. that said, we should look into improving this experience

I actually had to because (to my knowledge) nothing is incrementing it for me. So I had published an SDK 45 build to a release channel tied to 43.0.0 without realizing it. Should these lines be removed from Expo.plist and AndroidManifest entirely?

[brentvatne]

i've asked folks from the updates side to weigh in here, but until they do - you should update EXUpdatesSDKVersion to 45.0.0 to match the sdk version that you're using.

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[shamilovtim]

This needs a fix. Change the xml attribute from "major.minor.patch" to just an integer. Users shouldn't have to memorize / learn through tribal knowledge.

[ide]

Thanks for reporting this issue. From your report it looks like this affects the Classic Updates service (expo publish) which is in maintenance mode now the next-generation Expo Updates protocol and EAS Update service are generally available but we want to make sure this pitfall doesn't also affect modern Expo Updates.

For historical reasons that go back something like seven years, SDK versions have been of the form N.0.0 so we're hesitant to change that format due to seven years' worth of assumptions but there might be a safe change we can make e.g. if it's not too disruptive, require EXUpdatesSDKVersion to be N.0.0 for the build to succeed.

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity. If there is no activity in the next 7 days, the issue will be closed.

[github-actions[bot]]

This issue was closed because it has been inactive for 7 days since being marked as stale. Please open a new issue if you believe you are encountering a related problem.