Modifying In-App Purchase fails with ITC.response.error.OPERATION_FAILED - spaceship

[wufire]

Issue Description

Following the same steps found on this issue: #10216

I still see the OPERATION_FAILED itc response.

irb(main):005:0> p = app.in_app_purchases.all.first.edit
=> <Spaceship::Tunes::IAPDetail
...
>
irb(main):006:0> p.save!
Spaceship::TunesClient::ITunesConnectError: ITC.response.error.OPERATION_FAILED
	from /usr/local/lib/ruby/gems/2.4.0/gems/fastlane-2.62.1/spaceship/lib/spaceship/tunes/tunes_client.rb:212:in `handle_itc_response'
	from /usr/local/lib/ruby/gems/2.4.0/gems/fastlane-2.62.1/spaceship/lib/spaceship/tunes/tunes_client.rb:1074:in `block in update_iap!'
	from /usr/local/lib/ruby/gems/2.4.0/gems/fastlane-2.62.1/spaceship/lib/spaceship/tunes/tunes_client.rb:1406:in `with_tunes_retry'
	from /usr/local/lib/ruby/gems/2.4.0/gems/fastlane-2.62.1/spaceship/lib/spaceship/tunes/tunes_client.rb:1068:in `update_iap!'
	from /usr/local/lib/ruby/gems/2.4.0/gems/fastlane-2.62.1/spaceship/lib/spaceship/tunes/iap_detail.rb:205:in `save!'
	from (irb):6
	from /usr/local/bin/irb:11:in `<main>'

Environment

✅ fastlane environment ✅

Stack

Key	Value
OS	10.12.6
Ruby	2.4.2
Bundler?	false
Git	git version 2.9.2
Installation Source	/usr/local/bin/fastlane
Host	Mac OS X 10.12.6 (16G29)
Ruby Lib Dir	/usr/local/Cellar/ruby/2.4.2/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	9.0.1

System Locale

Variable	Value
LANG	en_US.UTF-8	✅
LC_ALL
LANGUAGE

fastlane files:

No Fastfile found

No Appfile found

fastlane gems

Gem	Version	Update-Status
fastlane	2.62.1	✅ Up-To-Date

Loaded fastlane plugins:

No plugins Loaded

Loaded gems

Gem	Version
did_you_mean	1.1.0
slack-notifier	1.5.1
CFPropertyList	2.3.5
claide	1.0.2
colored2	3.1.2
nanaimo	0.2.3
xcodeproj	1.5.2
rouge	2.0.7
xcpretty	0.2.8
terminal-notifier	1.8.0
unicode-display_width	1.3.0
terminal-table	1.8.0
plist	3.3.0
public_suffix	2.0.5
addressable	2.5.2
multipart-post	2.0.0
word_wrap	1.0.0
tty-screen	0.5.0
babosa	1.0.2
colored	1.2
highline	1.7.8
commander-fastlane	4.4.5
excon	0.59.0
faraday	0.13.1
unf_ext	0.0.7.4
unf	0.1.4
domain_name	0.5.20170404
http-cookie	1.0.3
faraday-cookie_jar	0.0.6
fastimage	2.1.0
gh_inspector	1.0.3
json	2.0.4
mini_magick	4.5.1
multi_json	1.12.2
multi_xml	0.6.0
rubyzip	1.2.1
security	0.1.3
xcpretty-travis-formatter	0.0.4
dotenv	2.2.1
bundler	1.15.4
faraday_middleware	0.12.2
uber	0.1.0
declarative	0.0.10
declarative-option	0.1.0
representable	3.0.4
retriable	3.1.1
mime-types-data	3.2016.0521
mime-types	3.1
little-plugger	1.1.4
logging	2.2.2
jwt	2.1.0
memoist	0.16.0
os	0.9.6
signet	0.8.1
googleauth	0.6.1
httpclient	2.8.3
google-api-client	0.13.6
io-console	0.4.6
openssl	2.0.5

generated on: 2017-10-30

[ohayon]

Hmmm. @wufire are you familiar with pry? It would be awesome if you could put a breakpoint in the handle_itc_response method and print out the actual error. 🐙

[wufire]

Ha, I'll try it out. Haven't used pry before, but no time to learn like the present 👍

[wufire]

I wasn't able to get very far, but now every login call is failing on an Invalid 2 step response which is probably unrelated.

When I get time, I'll have to figure out this login issue first before I can dive back in to the handle_itc_response debugging

[ohayon]

Thank you!

[wufire]

I was able to put a ruby environment together in a pry-able way. Here's what I see:

562: def request(method, url_or_path = nil, params = nil, headers = {}, auto_paginate = false, &block)
   563:   headers.merge!(csrf_tokens)
   564:   headers['User-Agent'] = USER_AGENT
   565:
   566:   # Before encoding the parameters, log them
   567:   log_request(method, url_or_path, params)
   568:
   569:   # form-encode the params only if there are params, and the block is not supplied.
   570:   # this is so that certain requests can be made using the block for more control
   571:   if method == :post && params && !block_given?
   572:     params, headers = encode_params(params, headers)
   573:   end
   574:
   575:   response = if auto_paginate
   576:                send_request_auto_paginate(method, url_or_path, params, headers, &block)
   577:              else
   578:                send_request(method, url_or_path, params, headers, &block)
   579:              end
   580:
=> 581:   log_response(method, url_or_path, response)
   582:
   583:   return response
   584: end

[8] pry(#<Spaceship::TunesClient>)> url_or_path
=> nil
[9] pry(#<Spaceship::TunesClient>)> response
=> #<Faraday::Response:0x00007ffd44ecaee8
=> #<Faraday::Response:0x00007ffd44ecaee8
@env=
 #<struct Faraday::Env
  method=:put,
  body=
   {"data"=>nil,
    "messages"=>
     {"warn"=>nil,
      "error"=>["ITC.response.error.OPERATION_FAILED"],
      "info"=>nil},
    "statusCode"=>"ERROR"},
  url=
   #<URI::HTTPS https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/ra/apps/962135460/iaps/1154666476>,
  request=
   #<struct Faraday::RequestOptions
    params_encoder=nil,
    proxy=nil,
    bind=nil,
    timeout=300,
    open_timeout=300,
    boundary=nil,
    oauth=nil,
    context=nil>,
  request_headers=
   {"User-Agent"=>"Spaceship 2.63.5",
    "Content-Type"=>"application/json",
    "Cookie"=>
     "acn01=3rPBNQ/Tn6k/gB7F95sAMA3b2boe57kSRRCXAEF43ipHox8=; dqsid=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJ2RmVEdXgyUFJjRXNtVjRkN0ZaWWJnIn0.EwUjAIgqefj73doanmH64TkWIkdQU8tlZ2j20UDH_40; dslang=US-EN; itcdq=1; itctx=eyJleCI6IjIwMTctMTEtMiAzOjUwOjE3IiwiY3AiOjIwODU1MzMsImRzIjoxMTUwMDcxNTI3NH0|37sqlel23mk1vvbj3cac1r7jlk|dDvLAZHkE2ydOaO0-yotrf58Udg; myacinfo=DAWTKNV2b93e8301c0bf379adbef33fcbf2648eca647aed47e9084c1e9a35d2d7df9dee1aafddb5b9a47d072fa9e36385cd81df17948d7a94721bd8aeee3a2aa2b17322eb044ceb0e4a5c1d17a03f42be25aada01c4a4220a92036790c6abb4822d81ec2b035eb55d4036478aca01e57e1216cdde21e422b0219732006e481d54e3f2883dd4f9079c9c37e417c7d39725fe99b34014f7e593c31751536ef15205656e02837331d3bfbc552603dcbcc93a92d01f370712cf769c7a9fd79f90f9af9780240b067938036f4d757ca8f3fe5f18c18f8dfe9f492926e4f4239d5136f231eae76a0afdd5f5c2cfc0685a538558fe19fcf34313032376262303362363331666164646566333561633431643835633535663332643265343066MVRYV2; site=USA; woinst=8210; wosid=CtL79kQVJlEmgyp3nfBvNw"},
  ssl=
   #<struct Faraday::SSLOptions
    verify=true,
    ca_file=nil,
    ca_path=nil,
    verify_mode=nil,
    cert_store=nil,
    client_cert=nil,
    client_key=nil,
    certificate=nil,
    private_key=nil,
    verify_depth=nil,
    version=nil>,
  parallel_manager=nil,
  params=nil,
  response=#<Faraday::Response:0x00007ffd44ecaee8 ...>,
  response_headers=
   {"server"=>"daiquiri/2.0.0",
    "content-type"=>"application/json; charset=utf-8;",
    "content-length"=>"124",
    "x-apple-jingle-correlation-key"=>"4EK5ZO3RNKKBIRNDXX33PEG7",
    "x-apple-application-site"=>"MR22",
    "apple-originating-system"=>"MZLabel",
    "strict-transport-security"=>"max-age=31536000; includeSubDomains;",
    "x-frame-options"=>"SAMEORIGIN",
    "apple-tk"=>"false",
    "apple-seq"=>"0.0",
    "apple-timing-app"=>"2382 ms",
    "cache-control"=>"private, no-cache, must-revalidate, max-age=0, no-store",
    "expires"=>"Thu, 01-Jan-1970 00:00:00 GMT",
    "x-apple-application-instance"=>"8210",
    "pragma"=>"no-cache",
    "x-webobjects-loadaverage"=>"73",
    "x-apple-request-uuid"=>"e115dcbb-716a-9414-45a3-bdf7b790df",
    "x-daiquiri-instance"=>"daiquiri-external:10100201:mr22p00it-ztbu06054301:9122:17N23",
    "date"=>"Wed, 01 Nov 2017 19:52:45 GMT",
    "connection"=>"close",
    "set-cookie"=>
     "dqsid=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJ2RmVEdXgyUFJjRXNtVjRkN0ZaWWJnIn0.EwUjAIgqefj73doanmH64TkWIkdQU8tlZ2j20UDH_40; Max-Age=1800; Expires=Wed, 01 Nov 2017 20:22:42 GMT; Path=/; Secure; HTTPOnly, wosid=CtL79kQVJlEmgyp3nfBvNw; version=\"1\"; path=/; secure; HttpOnly, woinst=8210; version=\"1\"; path=/; secure; HttpOnly"},
  status=500,
  reason_phrase="Internal Server Error">,
@on_complete_callbacks=[]>

[ohayon]

Interesting. It looks like its a 500. I would like to say that this is an issue on Apple's side of things, but I'm not totally sure. For how long has this been going on?

[wufire]

Yeah, that 500 is not a great sign...
I've only been trying it for about a week, but it looks like the previous issue (#10216) has been open since the end of August. No issues with create_iap, but modify is consistent with this error.

[ohayon]

Are you able to do this successfully via iTC on the web?

[wufire]

Yeah, it works through the browser on the same account on the same app.

[ohayon]

Hrmph. Its possible they changed something up on us as far as the API is concerned, if youre familiar with Charles Proxy and want to take a look at the traffic that would be amazing. Otherwise, we will try to handle this in the near future.

[wufire]

I'm not very familiar with Charles, and I'm not sure how much time I'll have to look, but if this is still open when I get a chance, I'll start digging around. Thanks for your help!

[ecornbower]

I get this same response when you don't include both the iap.versions and iap.review_screenshot variables before saving. This script works when you provide the screenshot file.

app = Spaceship::Application.find("com.test")
iap = app.in_app_purchases.all.first.edit

iap.versions = iap.versions
iap.review_screenshot = "iap.jpeg"
iap.save!

I added this ticket to address this issue but never received a response. There should be a way to either bypass the screenshot requirement or access the url to the existing screenshot so you don't need to keep the original screenshots around.

[ecornbower]

Looks like a user has created a fix for the issue in this ticket but has not completed a PR for it.

[wufire]

@kcornbower I tried to do a workaround modify by adding the screenshot (fortunately, I still have the original). I get the same OPERATION_FAILED error as before :(

[ecornbower]

@wufire Did you also add the iap.versions = iap.versions code? There is a bug in the current code and that line seems to fix it.

For anyone else experiencing this error, I'm in the process of tracking down the bug and will submit a PR when complete.

[wufire]

Yeah, I thought the same thing, too. :D Same result, unfortunately.

[ecornbower]

That's odd, I'll be done with my PR in the next few days and you can try that and see if it fixes your issue as well.

[taijizhu]

blocked on this as well, manually copy/paste over 100 strings is rather painful on the shoulder.

[ohayon]

Just merged @kcornbower's PR, I am going to close this issue for now, let us know if there are still issues! 🚀

[wufire]

Hmm, I'm on 2.68.2 and I'm still seeing an OPERATION_FAILED issue.

I'm wondering if mine's is a special case.
We had submitted an initial version which was rejected, along with all our IAPs.
I am attempting to do a minor edit to each purchase's localization data to move them from Developer Action Needed to Ready for Review.

It's possible the rejection state is causing this problem, but I'm not sure how to go about testing that. Should I file this as a separate issue, or keep this one open?

[ecornbower]

@wufire That sounds likely that it has to do with the rejected IAPs. The current code does not work properly unless the IAP is not approved yet. You can still edit approved IAPs and the changes will be uploaded, but it will show an OPERATION_FAILED message like you are seeing. Did you notice if the changes are actually taking place even though the error message displays?

That said I would personally not recommend using Fastlane to edit approved IAPs. There are a lot of parameters that do not match what the real iTunes Connect is currently using, so that code would need to be redone in the future.

[wufire]

Ah, I see. That makes sense to me.

Some changes work! Things like ready_for_sale definitely update.
So far as I can tell, the Localization data never works (which is what I'm mainly interested in changing)

Thanks for the info