fastlane: 765: unexpected token at 'Bad Request' when calling to provisioningProfile.update!

New Issue Checklist

Issue Description

The following code crashes with

/Users/pbeast/.gems/gems/json-2.1.0/lib/json/common.rb:156:in ‘parse’: 765: unexpected token at ‘Bad Request’ (Faraday::ParsingError) from /Users/pbeast/.gems/gems/json-2.1.0/lib/json/common.rb:156:in ‘parse’ from /Users/pbeast/.gems/gems/faraday_middleware-0.12.2/lib/faraday_middleware/response/parse_json.rb:11:in ‘block in class:ParseJson’ from /Users/pbeast/.gems/gems/faraday_middleware-0.12.2/lib/faraday_middleware/response_middleware.rb:51:in ‘parse’ from /Users/pbeast/.gems/gems/faraday_middleware-0.12.2/lib/faraday_middleware/response_middleware.rb:40:in ‘process_response’ from /Users/pbeast/.gems/gems/faraday_middleware-0.12.2/lib/faraday_middleware/response_middleware.rb:33:in ‘block in call’ from /Users/pbeast/.gems/gems/faraday-0.13.1/lib/faraday/response.rb:61:in ‘on_complete’ from /Users/pbeast/.gems/gems/faraday_middleware-0.12.2/lib/faraday_middleware/response_middleware.rb:31:in ‘call’ from /Users/pbeast/.gems/gems/faraday-0.13.1/lib/faraday/rack_builder.rb:141:in ‘build_response’ from /Users/pbeast/.gems/gems/faraday-0.13.1/lib/faraday/connection.rb:387:in vrun_request’ from /Users/pbeast/.gems/gems/faraday-0.13.1/lib/faraday/connection.rb:174:in ‘post’ from /Users/pbeast/.gems/gems/fastlane-2.68.2/spaceship/lib/spaceship/client.rb:724:in ‘block in send_request’ from /Users/pbeast/.gems/gems/fastlane-2.68.2/spaceship/lib/spaceship/client.rb:559:in ‘with_retry’ from /Users/pbeast/.gems/gems/fastlane-2.68.2/spaceship/lib/spaceship/client.rb:723:in ‘send_request’ from /Users/pbeast/.gems/gems/fastlane-2.68.2/spaceship/lib/spaceship/client.rb:611:in ‘request’ from /Users/pbeast/.gems/gems/fastlane-2.68.2/spaceship/lib/spaceship/portal/portal_client.rb:672:in ‘repair_provisioning_profile!’ from /Users/pbeast/.gems/gems/fastlane-2.68.2/spaceship/lib/spaceship/portal/provisioning_profile.rb:459:in ‘block in update!’ from /Users/pbeast/.gems/gems/fastlane-2.68.2/spaceship/lib/spaceship/client.rb:559:in ‘with_retry’ from /Users/pbeast/.gems/gems/fastlane-2.68.2/spaceship/lib/spaceship/portal/provisioning_profile.rb:458:in ‘update!’ from ./fastlane/sample.rb:49:in ‘<main>’

The code below is cut-out from the much longer script. By fail-and-retry, I found that issue was introduced with fastlane v2.67.0 (v2.66.2 works fine)

#!/usr/bin/env ruby

require 'spaceship'

spaceship = Spaceship::Portal.login("xxx")
puts "Logged-in to Dev Portal".green
spaceship.team_id = 'xxx'

all_profiles = Spaceship::Portal.provisioning_profile.development.all

profiles = all_profiles.find_all do |profile|
  profile.app.bundle_id == "com.xxx.xxx"
end

if !profiles.nil? && profiles.size > 0
  if profiles.size > 1
    UI.important("Multiple profiles found: #{profiles.size}. Deleting all to avoid inconsistency")
    profiles.each { |p|
      #deleteLocalProvisioningProfile(p.uuid)
      p.delete!
    }
  else
    profile = profiles.first

    puts "Found provisioning profile '#{profile.name}' for app: #{profile.app.name}"

    profileName = "xxx Development"
    puts "Making sure profile name is '#{profileName}'"

    profile.name = profileName

    if !profile.valid? || !profile.certificate_valid?
      puts "Profile is broken. Will be fixed..."
    end

    puts "Updating profile devices".green
    profile.devices = Spaceship::Portal.device.all

    certificates = Spaceship::Portal.certificate.development.all

    puts "Assigning code signing certificates:".green
    certificates.each { |c|
      puts "	#{c.owner_name}(#{c.name})"
    }

    profile.certificates = certificates

    puts "Updating profile at development portal".green
    profile.update!

    #deleteLocalProvisioningProfile(profile.uuid)
  end
end

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 21 (13 by maintainers)

Commits related to this issue

Most upvoted comments

Will do

Regards, Pavel Yankelevich

On 30 Dec 2017, 20:07 +0200, Felix Krause notifications@github.com, wrote:

So, probably the easiest fix is to force the token update by always calling PortalClient::fetch_csrf_token_for_provisioning at the beginning of PortalClient::repair_provisioning_profile!, regardless to cache state Sounds like a great approach to me 😃 Wanna submit a PR for it? 👍 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

I’m having a difficult time reproducing this with my own account. Any chance you could you run this script and capture the request and response that is being made? I think that would point us in the right direction. There must be some piece of data that the server doesn’t like.