fastlane: Pilot upload fails with Server error got 500. build.processed? returns true even though the build is still being processed on App Store Connect
New Issue Checklist
- Updated fastlane to the latest version
- I read the Contribution Guidelines
- I read docs.fastlane.tools
- I searched for existing GitHub issues
Issue Description
I am using fastlane pilot upload --verbose to upload several different apps. I have noticed for apps that are larger in size after a couple of waiting for App Store Connect to finish processing the new build:
INFO [2018-11-28 08:46:27.04]: Waiting for App Store Connect to finish processing the new build (1.3.0 - 1.3.0)
INFO [2018-11-28 08:46:57.98]: Waiting for App Store Connect to finish processing the new build (1.3.0 - 1.3.0)
INFO [2018-11-28 08:47:29.25]: Waiting for App Store Connect to finish processing the new build (1.3.0 - 1.3.0)
INFO [2018-11-28 08:48:00.05]: Waiting for App Store Connect to finish processing the new build (1.3.0 - 1.3.0)
INFO [2018-11-28 08:48:30.92]: Waiting for App Store Connect to finish processing the new build (1.3.0 - 1.3.0)
INFO [2018-11-28 08:49:01.86]: Waiting for App Store Connect to finish processing the new build (1.3.0 - 1.3.0)
INFO [2018-11-28 08:49:33.29]: Waiting for App Store Connect to finish processing the new build (1.3.0 - 1.3.0)
INFO [2018-11-28 08:50:04.51]: Waiting for App Store Connect to finish processing the new build (1.3.0 - 1.3.0)
INFO [2018-11-28 08:50:34.96]: Waiting for App Store Connect to finish processing the new build (1.3.0 - 1.3.0)
INFO [2018-11-28 08:51:05.47]: Waiting for App Store Connect to finish processing the new build (1.3.0 - 1.3.0)
I get a Server error 500 [31m[!] The request could not be completed because: (Spaceship::InternalServerError).
As stated earlier this happens for larger binaries, the apps with smaller binaries do not have any issues. Hence I do not think it is related to setting <key>ITSAppUsesNonExemptEncryption</key><false/> in the info.plist file. As both larger and smaller binaries do not have this key set.
I have tried to investigate further using Spaceship and have noticed that build.processed? returns true and build.processing? returns false even though on App Store Connect I see that the build is still being processed:
Are there other attributes that I should look at? Why is the state inconsistent?
Complete output when running fastlane, including the stack trace and command used
Environment
| Key | Value | | --------------------------- | ------------------------------------------- | | OS | 10.12.6 | | Ruby | 2.3.1 | | Bundler? | false | | Git | git version 2.11.0 (Apple Git-81) | | Installation Source | ~/.rvm/gems/ruby-2.3.1/bin/fastlane | | Host | Mac OS X 10.12.6 (16G29) | | Ruby Lib Dir | ~/.rvm/rubies/ruby-2.3.1/lib | | OpenSSL Version | OpenSSL 1.0.2l 25 May 2017 | | Is contained | false | | Is homebrew | false | | Is installed via Fabric.app | false | | Xcode Path | /Applications/Xcode.app/Contents/Developer/ | | Xcode Version | 8.3.3 |System Locale
| Variable | Value | |
|---|---|---|
| LANG | en_US.UTF-8 | ✅ |
| LC_ALL | en_US.UTF-8 | ✅ |
| LANGUAGE |
fastlane files:
No Fastfile found
No Appfile found
fastlane gems
| Gem | Version | Update-Status |
|---|---|---|
| fastlane | 2.108.0 | ✅ Up-To-Date |
Loaded fastlane plugins:
No plugins Loaded
Loaded gems
| Gem | Version |
|---|---|
| did_you_mean | 1.0.0 |
| slack-notifier | 2.3.2 |
| rouge | 2.0.7 |
| xcpretty | 0.3.0 |
| terminal-notifier | 1.8.0 |
| terminal-table | 1.8.0 |
| plist | 3.4.0 |
| public_suffix | 2.0.5 |
| addressable | 2.5.2 |
| multipart-post | 2.0.0 |
| word_wrap | 1.0.0 |
| tty-spinner | 0.8.0 |
| babosa | 1.0.2 |
| colored | 1.2 |
| highline | 1.7.10 |
| commander-fastlane | 4.4.6 |
| http-cookie | 1.0.3 |
| faraday-cookie_jar | 0.0.6 |
| gh_inspector | 1.1.3 |
| mini_magick | 4.5.1 |
| multi_json | 1.13.1 |
| multi_xml | 0.6.0 |
| rubyzip | 1.2.2 |
| security | 0.1.3 |
| xcpretty-travis-formatter | 1.0.0 |
| bundler | 1.16.1 |
| faraday_middleware | 0.12.2 |
| emoji_regex | 0.1.1 |
| tty-cursor | 0.6.0 |
| tty-screen | 0.6.5 |
| faraday | 0.15.3 |
| json | 2.1.0 |
| io-console | 0.4.5 |
| excon | 0.62.0 |
| CFPropertyList | 3.0.0 |
| atomos | 0.1.3 |
| claide | 1.0.2 |
| colored2 | 3.1.2 |
| nanaimo | 0.2.6 |
| xcodeproj | 1.7.0 |
| jwt | 2.1.0 |
| signet | 0.10.0 |
| uber | 0.1.0 |
| declarative | 0.0.10 |
| declarative-option | 0.1.0 |
| representable | 3.0.4 |
| httpclient | 2.8.3 |
| google-api-client | 0.23.9 |
| memoist | 0.16.0 |
| googleauth | 0.6.6 |
| unf | 0.1.4 |
| domain_name | 0.5.20180417 |
| fastimage | 2.1.4 |
| unicode-display_width | 1.4.0 |
| simctl | 1.6.5 |
| retriable | 3.1.2 |
| mime-types | 3.2.2 |
| mime-types-data | 3.2018.0812 |
| os | 1.0.0 |
| psych | 2.0.17 |
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 4
- Comments: 30 (10 by maintainers)
I also got the
Bad Gatewayerror (fastlane 2.108) turns out I just had to login as the testflight user to itunes connect in the browser and accept a terms of service notice. Hope that helps someone.https://github.com/fastlane/fastlane/blob/1af33c0884e783867bdc07a324280ec6bef124ad/fastlane_core/lib/fastlane_core/build_watcher.rb#L59
The core of the issue is that
build.export_compliance_missing?returnstrue. This is assumed to mean that the build has finishes processing. But that is not the case.This is affecting almost every TestFlight upload that we do!
@kevinm90 - If you are seeing this sporadically and you have the compliance flag set to false, can you confirm which upload tool you are using? Im using the default Fastlane one, iMSTransporter. I have my own CLI tool that uses altool and I have never encountered this problem. So if you are have the flag set to false and are using iMSTransporter then my gut says its the iMSTransporter component thats timing out or Fastlane’s logic that wraps that process. Can anyone from Fastlane comment on this?