Doorkeeper: Doorkeeper initialization autoload - warning

Created on 18 Jun 2019  路  19Comments  路  Source: doorkeeper-gem/doorkeeper

After upgrading to Rails 6.0.0.rc1, the doorkeeper initializer triggers a warning on server start with the following:

DEPRECATION WARNING: Initialization autoloaded the constant RedirectUriValidator.

I believe this has to do w/ the new zeitwerks loader and moving away from autoloading behavior from within initializers.

Has anyone run into this? Not sure how to fix this since this seems to be happening with Doorkeeper itself.

enhancement

Most helpful comment

@nbulaj PR attached

All 19 comments

Hi @jasonjho . Thanks for reporting this!

@jasl I remember you did some refactoring in order to add support for Rails 6, could you please take a look at this?

@nbulaj I'll check this later, Rails 6 rc1 change too much than beta2 so it may breaking

@nbulaj @jasonjho

I pulled the master and bundle update, there's no warning on rails s and rails spec.

@jasonjho which version of doorkeeper you in use? could you try latest master branch? could you diff your doorkeeper initializer with the latest?

Thank you!

Hi @jasonjho ! Any updates here?

For me it's the same result (Doorkeeper 5.2.rc2 and Rails 6.0.rc1):

image

Hi @nbulaj @jasl I tested this using doorkeeper 5.2.0.rc2 and rails6.0.0.rc1 and I'm still seeing the following warning:

DEPRECATION WARNING: Initialization autoloaded the constant RedirectUriValidator.

Being able to do this is deprecated. Autoloading during initialization is going
to be an error condition in future versions of Rails.

Reloading does not reboot the application, and therefore code executed during
initialization does not run again. So, if you reload RedirectUriValidator, for example,
the expected changes won't be reflected in that stale Class object.

This autoloaded constant has been unloaded.

Running rails s doesn't actually show an error on startup. I only see this deprecation warning show up in the development logs. @nbulaj do you see any of this in your dev or production logs on initialization? I'm pretty sure it's from the doorkeeper init file -- since removing will cause the warning to go away.

Actually I think it related not to initializer itself, but to Rails autoloading. Seems like it autoloads all the files under app/ directory and now it is deprecated. And we have such file - it's RedirectUriValidator. Need to check how to load such files now with Zeitwerk

@nbulaj Yep! We've actually seen this quite a bit with other dependencies. Definitely a side effect with the new zeitwerk loading mechanism.

In the meantime, the short term (or maybe even long?) fix is to simply require 'redirect_uri_validator' at the top of the initializer.

OK, so I need to create a new project to take a look.

It is strange that I have a Rails 6.0.0.rc1 project with Doorkeeper and I'm not find this issue, or maybe I'm not notice that.

Any chances to fix it for 5.2 release :pray: ? I can't reproduce myself :(

@nbulaj
I'll try this tonight, will reply if I can or I can not reproduce it

@nbulaj

Using doorkeeper 5.2.0.rc2 from https://github.com/doorkeeper-gem/doorkeeper.git (at master@5277f4a)
Using doorkeeper-i18n 5.0.2
Using doorkeeper-openid_connect 1.6.1
Using rails 6.0.0.rc2
Using zeitwerk 2.1.9
Using bundler 2.0.2

I still can't reproduce the warning.

@jasl maybe try to enable admin panel and try to create an application. Seems like deprecation connected to redirect uri validator, so we need to call it. Maybe enable eager loading I don't know...

@nbulaj

Still can't reproduce, I don't think putting RedirectUriValidator in app/validators breaks the rule of Zeitwerk, and in rails console type RedirectUriValidator can get the class correctly, so I don't know how to trigger this.

But, I think there's a simple & stupid way to prevent the issue, we can just move the validator from app/validators to lib/doorkeeper/validators, and require it manually in lib/doorkeeper.rb

It will be good, but only for _active_record_ orm (not sequel, mongoid or any other)

@nbulaj PR attached

Thanks @jasl for your work! I think we can close this issue, but @jasonjho feel free to ping me if it didn't solve your problem

@nbulaj I think my issue is related to this based on your comment. @jasl I have repro steps here with the v5.2.2 release.

BTW, In Rails 6, we no longer need any kinds of require_dependency, and a reference change are https://github.com/rails/rails/commit/1d2a2d9143556460cd44e17ab3553091a182cd0b

Was this page helpful?
0 / 5 - 0 ratings