-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Authentication with cookies unreliable on 5.6.0 #2808
Comments
We experienced similar issue.. upgrading to puma 5.6.0 breaks a lot of our cypress e2e tests reliably because the user session used by the test runner gets invalidated.. |
This might be related even though we're using puma as a Capybara server and rack_session_access (which provides access to a cookie setter for testing). An isolated PR (opf/openproject#10098) bumping just Puma is reporting deadlocks in Rack::Lock:
|
Similar issue here. But not related with cookies at all. We are getting different accounts every five requests or so, specifically at this point of the code: def current_user
Current.user ||= User.active.find_by api_key: params[:api_key]
end |
Shot in the dark here but if you have a specific test that's failing (@pedantic-git @ignatiusreza) can you try the following two git checkouts?
and
|
If you've got the time, bisecting your failing test for the commits between 5.5.2 and 5.6.0 would help immensely. |
Very happy to! One moment please. |
Ah - they became links! How nice! I can see that narrows it down to one commit already. |
Yeah, there's no commits between those two so that means it's probably |
I rolled back f8acac1 from 61ebbbe (5.6.0 commit) locally and this reliably fixes our capybara/puma deadlocks. |
@MSP-Greg @nateberkopec Let's do the revert and a new release and then look at what's wrong, I opened #2809 reverting the offending commit |
I can confirm that running the same cypress spec locally failed 2 out of 3 times with the 5.6.0 release, and are passing 3 out of 3 with the reverted commit 👍 |
@pedantic-git Trying to run your specs but getting ➜ name.pn git:(af3864d) docker-compose run web spinach features/signup_and_edit_profile.feature
Creating namepn_web_run ... done
#<Thread:0x000055a9ac11eee0 /usr/src/app/vendor/bundle/gems/semantic_logger-4.9.0/lib/semantic_logger/appender/async.rb:77 run> terminated with exception (report_on_exception is true):
/usr/src/app/vendor/bundle/gems/semantic_logger-4.9.0/lib/semantic_logger/appender/file.rb:172:in `initialize': Permission denied @ rb_sysopen - /usr/src/app/log/test.log (Errno::EACCES) |
Oh yeah I always forget that not everyone's user id is 1001! You can either set the |
@pedantic-git Got a little further: https://gist.github.com/baelter/817933f1d1dcb89f5beaf1c6fa1cee2b |
Oops! You'll need to run |
5.6.1 is out with a rollback of that commit. I'll leave this open until we figure out what exactly went wrong, the impact, and add a test. |
Huge thanks to @ignatiusreza and @pedantic-git for the test failures here. I had a good guess as to where the problem might be but your test fails made this a much faster fix. |
This issue was fixed with 5.6.2/4.3.10. |
Describe the bug
[Sorry this is so vague - I don't know what the exact bug is but it seemed important enough to report.]
I had a bunch of automated test failures after upgrading to 5.6.0. Specifically this set of tests - name.pn is open source and Dockerized so you could theoretically run them yourself to see the same thing.
The issue seems to be that the Rails session cookie (I use Devise for authentication) isn't being recognised in some situations and the test is failing because the user is unauthenticated.
I confirmed that downgrading Puma to 5.5.2 returns the tests to 100% reliability, but I honestly don't know where to start on why this would be an issue. Let me know if there's any more debugging I can do.
Puma config:
Puma 5.6.0
To Reproduce
(Spinach is similar to Cucumber, and spins up its own copy of the app inside a Puma to run the tests against)
It doesn't fail 100% of the time and it seems to only do it when a bunch of tests are run together - they usually pass when run individually. When they fail, screenshots are output into tmp/capybara.
Sorry this is hardly an easy set of reproduction steps and it sounds like I'm expecting you to understand my app. If I understood the issue better than I do I'd file a better bug report than this!
Expected behavior
The tests pass, as they do when I downgrade Puma to 5.5.2.
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: