Faraday: Breaking changes for fastlane in 0.16.2

Created on 29 Sep 2019 · 15Comments · Source: lostisland/faraday

Basic Info

Faraday Version: 0.16.2
Ruby Version:
- Windows: ruby 2.4.6p354 (2019-04-01 revision 67394) [x64-mingw32]
- Mac: Ruby 2.5

Issue description

Even with faraday 0.16.2 and the fixes of @BobbyMcWho there are test failures for fastlane:

Failures:
  1) Spaceship::Portal::Persons should change role
     Failure/Error: expect { person.change_role("member") }.to_not(raise_error)
       expected no Exception, got #<RuntimeError: can't modify frozen String> with backtrace:
         # ./spaceship/lib/spaceship/client.rb:811:in `force_encoding'
         # ./spaceship/lib/spaceship/client.rb:811:in `log_response'
         # ./spaceship/lib/spaceship/client.rb:846:in `block in send_request'
         # ./spaceship/lib/spaceship/client.rb:620:in `with_retry'
         # ./spaceship/lib/spaceship/client.rb:844:in `send_request'
         # ./spaceship/lib/spaceship/client.rb:688:in `request'
         # ./spaceship/lib/spaceship/portal/portal_client.rb:449:in `team_set_role'
         # ./spaceship/lib/spaceship/portal/person.rb:45:in `change_role'
         # ./spaceship/spec/portal/person_spec.rb:58:in `block (3 levels) in <top (required)>'
         # ./spaceship/spec/portal/person_spec.rb:58:in `block (2 levels) in <top (required)>'
     # ./spaceship/spec/portal/person_spec.rb:58:in `block (2 levels) in <top (required)>'
  2) Spaceship::Tunes::IAPList IAPList can delete
     Failure/Error: deleted = app.in_app_purchases.find("go.find.me").delete!
     RuntimeError:
       can't modify frozen String
     # ./spaceship/lib/spaceship/client.rb:811:in `force_encoding'
     # ./spaceship/lib/spaceship/client.rb:811:in `log_response'
     # ./spaceship/lib/spaceship/client.rb:846:in `block in send_request'
     # ./spaceship/lib/spaceship/client.rb:620:in `with_retry'
     # ./spaceship/lib/spaceship/client.rb:844:in `send_request'
     # ./spaceship/lib/spaceship/client.rb:688:in `request'
     # ./spaceship/lib/spaceship/tunes/tunes_client.rb:1235:in `delete_iap!'
     # ./spaceship/lib/spaceship/tunes/iap_list.rb:72:in `delete!'
     # ./spaceship/spec/tunes/iap_list_spec.rb:28:in `block (3 levels) in <top (required)>'
  3) Spaceship::Tunes::Members members creates a new member role: admin, apps: all
     Failure/Error: Spaceship::Members.create!(firstname: "Helmut", lastname: "Januschka", email_address: "[email protected]")
     RuntimeError:
       can't modify frozen String
     # ./spaceship/lib/spaceship/client.rb:811:in `force_encoding'
     # ./spaceship/lib/spaceship/client.rb:811:in `log_response'
     # ./spaceship/lib/spaceship/client.rb:846:in `block in send_request'
     # ./spaceship/lib/spaceship/client.rb:620:in `with_retry'
     # ./spaceship/lib/spaceship/client.rb:844:in `send_request'
     # ./spaceship/lib/spaceship/client.rb:688:in `request'
     # ./spaceship/lib/spaceship/tunes/tunes_client.rb:502:in `create_member!'
     # ./spaceship/lib/spaceship/tunes/members.rb:26:in `create!'
     # ./spaceship/spec/tunes/members_spec.rb:19:in `block (4 levels) in <top (required)>'

...

PR for reference: https://github.com/fastlane/fastlane/pull/15407

Note that our tests are not failing on ruby 2.3 on macOS and Ubuntu.

Source

janpio

Most helpful comment

@janpio I suspect #1039 should fix the issues with frozen string literals in the body.

BobbyMcWho on 30 Sep 2019

❤2

All 15 comments

This should be fixed by this line in fastlane/fastlane#15403, I think it's a side effect of a frozen string literal magic comment somewhere

Edit: ~that can't be released until lostisland/faraday_middleware#196 is approved and released~ Edit2: it's backward compatible

BobbyMcWho on 29 Sep 2019

Yes, the path forward is quite clear here - and we will cut a new release with that as soon as feasable.

But there are thousands of Fastlane installs (and other software) out there broken right now, which is why I thought it was important to report this explicitly again.

Is there a way to make this work again in a 0.16.3?

janpio on 29 Sep 2019

I'm not at a place where I can get to a computer but from a cursory glance browsing through files on my phone it seems to me that somewhere in Faraday we're setting the request body to a frozen string. if we can find where that request body is being set to a frozen string then that should fix the issue in fast lane

BobbyMcWho on 29 Sep 2019

👍1

@janpio I suspect #1039 should fix the issues with frozen string literals in the body.

BobbyMcWho on 30 Sep 2019

❤2

Thanks for hanging in there while the fixes turned up. Thanks BobbyMcWho for implementing!

I'm curious if there were any _more_ mutable body strings needed in other adapters?

olleolleolle on 30 Sep 2019

I took a look through the project, nothing else immediately sticks out to me, most frozen literals are error messages, or are being used in ways that wouldn't expect them to be mutable

BobbyMcWho on 1 Oct 2019

I also experienced this when using faraday 0.16.2 with elasticsearch-transport (a dependency of searchkick). Thanks for putting a patch in @BobbyMcWho!

zspencer on 3 Oct 2019

@zspencer you might have to point at the 0.16.x branch in your gemfile if you need it right now, until the maintainers have a chance to release 0.16.3

BobbyMcWho on 3 Oct 2019

👍1

Thanks! I have already done so. I wanted to make sure that people who were running into this issue and adding words like searchkick and elasticsearch to their google queries would find the issue. (and the fix!)

zspencer on 5 Oct 2019

Hello everyone, we are really sorry for all the disruptions caused by the v0.16.x releases.
We've just performed a ROLLBACK RELEASE v0.17.0 which follows directly the latest working release v0.15.4.
Please update to that version to solve the backwards-compatibility issues.
More info here: https://github.com/lostisland/faraday/releases/tag/v0.17.0

iMacTia on 6 Oct 2019

Thanks @iMacTia, will this also apply to faraday_middleware which we until now kept at the same version as faraday?

janpio on 7 Oct 2019

@janpio I'm sorry I'm not sure I understand. This issue should not affect faraday_middleware in any way as we didn't release any new version of it since February.
I'm aware of this PR which aims to add compatibility with 0.16, but that won't be released anymore.

Once we release Faraday v1.0 we'll also update Faraday Middleware and release a compatible v1.0.

Please let me know if you were asking about something else 😄

iMacTia on 7 Oct 2019

More or less - in our gemspec faraday_middleware was commented with in sync with faraday so I was wondering if there actually needs to be a newer version. If that is not the case, we will just keep using an older one.

janpio on 7 Oct 2019

Faraday Middleware v0.13.1 was working fine with Faraday v0.15.4, so I'd expect it to work as well with v0.17.0. I'll trigger a master build though just to be sure 👍

iMacTia on 8 Oct 2019

@janpio triggered https://travis-ci.org/lostisland/faraday_middleware/builds/595051325, you can see in logs that Faraday v0.17.0 is used and all tests are passing 🎉

iMacTia on 8 Oct 2019

❤1

Was this page helpful?

0 / 5 - 0 ratings