Having a @request variable defined in user's controller could be problematic#144
Having a @request variable defined in user's controller could be problematic#144
Conversation
|
@cryptogopher Could you please test this branch in your app? NOTE Those CI failures seem totally unrelated ("uninitialized constant ActiveSupport::LoggerThreadSafeLevel::Logger"), specs are passing fine ✅ for me locally. They seem to fail only in Rails < v7.1. NOTE 2 CI failures seem to be related with this: rails/rails#54264 |
|
All is good, thank you |
|
Cool 👌🏼 thanks for checking! I'll see how can I resolve those CI failures and release a new version soon (probably this week). |
|
Regarding CI failures: if I'm not mistaken, there is a problem with gem 'concurrent-ruby' 1.3.5. You can try to pin it to 1.3.4 and see if it helps. |
|
That change must have broken many CIs! I think it should be fixed upstream, it doesn't make a lot of sense 😅 to force a whole community of library maintainers to pin to specific versions and make changes to fix some incompatibilities with gems that we don't even use. |
|
@cryptogopher I just pushed a workaround for the |
|
UPDATE It seems this code (access to the |
|
@cryptogopher Seems that 54c9656 fixed the build, I'd say this is ready ✅ |
Closes #105
More details 👉🏼 #105 (comment). It seems we probably don't need to memoize this variable ... so instead of renaming it to something like
@_current_request(which will also fix the issue), I think we can just ✂️