Skip to content
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

Sorcery breaks Rails defaults from initializers for ActiveRecord #312

Open
brandoncc opened this issue May 15, 2022 · 2 comments
Open

Sorcery breaks Rails defaults from initializers for ActiveRecord #312

brandoncc opened this issue May 15, 2022 · 2 comments
Labels
bug Something isn't working implemented in v1 This issue or pull request has been resolved in the v1 rework codebase

Comments

@brandoncc
Copy link

We are working on upgrading a Rails 5 app and the Rails 5.2 update adds new_framework_defaults_5_2.rb with:

# Rails.application.config.active_record.cache_versioning = true

When that is commented, cache keys look like this:

irb(main):001:0> User.last.cache_key
  User Load (0.1ms)  SELECT  "users".* FROM "users" ORDER BY "users"."id" DESC LIMIT ?  [["LIMIT", 1]]
=> "users/1-20220515125125626825"

When it is uncommented, it changes the output to this:

irb(main):001:0> User.last.cache_key
  User Load (0.1ms)  SELECT  "users".* FROM "users" ORDER BY "users"."id" DESC LIMIT ?  [["LIMIT", 1]]
=> "users/1"

When I add sorcery to the project, though, the cache key reverts to the former version.

If I comment sorcery out in the Gemfile, then the cache key is the correct value again.

I have created a reproduction app, with exact reproduction instructions in the readme, here.


I believe this is happening because sorcery loads ActiveRecord too early. I debugged similar issues with recaptcha and wicked_pdf for ApplicationController.

You can see how recaptcha fixed it by converting to using a railtie here.

You can see how wicked_pdf fixed it the same way here.

I realize sorcery supports frameworks other than Rails, but I'm hoping that a Rails check can be used to fix this. If the application is a Rails application, then load using ActiveSupport.on_load. Otherwise, load as it currently does. I saw that engine.rb references needing to do this for ActionController too, but there are issues for pre-existing code.

I'd be happy to create a PR, but I'm not sure about the issues that pre-existing code was experiencing.

Configuration

  • Sorcery Version: master
  • Ruby Version: 2.6.10
  • Framework: Rails 5.2, presumably up to main branch
  • Platform: MacOS

Expected Behavior

Rails initializers for ActiveRecord should work.

Actual Behavior

They do not necessarily work

Steps to Reproduce

Please see https://github.com/brandoncc/sorcery-error-reproduction-rails-app.

@joshbuker
Copy link
Member

The way Sorcery currently loads has caused a plethora of issues, I wouldn't be surprised if this is one of them.

Sorcery v1 will use a railtie and properly hook into the bootstrapping system. That said, I have unfortunately been incredibly behind schedule on pushing v1 to a production ready state.

The conditional loading depending on if Rails is present has been tried, and unfortunately breaks things horribly. The easiest solution to this would probably be to finish Sorcery v1. I'm not sure if there's any workarounds can be be used in the meantime, but if there are please post them here for others that may be running into the same issue!

@joshbuker joshbuker added bug Something isn't working implemented in v1 This issue or pull request has been resolved in the v1 rework codebase labels May 18, 2022
@brandoncc
Copy link
Author

brandoncc commented May 20, 2022

Thanks for letting me know about this. The only workaround we have come up with is to move the default overrides from the initializer that rails app:update generates into application.rb just after the load_defaults line. It seems to work okay, but isn't a great solution.

There is also a PR open on the rails repo discussing how to fix this for the whole ecosystem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working implemented in v1 This issue or pull request has been resolved in the v1 rework codebase
Projects
None yet
Development

No branches or pull requests

2 participants