Fix NameError on doorkeeper master by deferring AR model loading in run_hooks#241
Merged
Merged
Conversation
Copilot created this pull request from a session on behalf of
nbulaj
April 10, 2026 07:42
View session
Closed
…eeper master compatibility Agent-Logs-Url: https://github.com/doorkeeper-gem/doorkeeper-openid_connect/sessions/3bd0d488-d252-45df-af57-b71509b8e6d5 Co-authored-by: nbulaj <1443426+nbulaj@users.noreply.github.com>
nbulaj
force-pushed
the
copilot/fix-doorkeeper-gemfile-tests
branch
from
afe65ae to
c5b220d
Compare
nbulaj
approved these changes
Apr 13, 2026
nbulaj
left a comment
nbulaj
left a comment
Member
There was a problem hiding this comment.
OK I added a few changes, now looks OK
Merged
55728
added a commit
to 55728/doorkeeper-openid_connect
that referenced
this pull request
Jun 16, 2026
…eper-gem#306) Namespaced custom access grant models (e.g. `Auth::OAuthAccessGrant < ApplicationRecord`) crashed on Rails boot since v1.10.0 with `NameError: uninitialized constant Auth::ApplicationRecord`. v1.10.0 (doorkeeper-gem#241) wrapped the access-grant prepend in `ActiveSupport.on_load(:active_record)`, following doorkeeper #1804. doorkeeper reverted that approach in #1830 (v5.9.2): the load hook fires while `ActiveRecord::Base` is first loaded — mid-evaluation of `class ApplicationRecord < ActiveRecord::Base` — so constantizing a namespaced grant model from the hook resolves `ApplicationRecord` before `::ApplicationRecord` is registered, raising the NameError. Follow doorkeeper #1830: drop the `run_hooks`/`initialize_models!` overrides and the on_load block, and instead prepend an extension onto the singleton class of `Doorkeeper::Orm::ActiveRecord::Mixins::AccessGrant`. Its `included` callback adds the `openid_request` association when the host model includes the mixin — at the model's own load time, with `base` handed in by Ruby. Nothing constantizes the configured grant class, so the re-entrant load window is gone. The string `class_name:` keeps the association target resolved lazily by ActiveRecord. The prepend is guarded with `base.is_a?(Class)`: when the mixin is included into an intermediate ActiveSupport::Concern, the hook first fires with that module as `base`, and the deferred include fires it again with the actual model class. The legacy `active_record_options[:establish_connection]` handling moves into the OpenidRequest mixin's `included` block (guarded; a no-op on doorkeeper 5.9.x, which no longer exposes `active_record_options`). Adds regression coverage: a namespaced custom model that includes the doorkeeper mixin is wired with the `openid_request` association.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes failing tests when using
doorkeeper_master.gemfile(doorkeeper ≥ 5.9.0).Background
Doorkeeper #1804 (landed in v5.9.0) wrapped
initialize_configured_associationsinsideActiveSupport.on_load(:active_record)to prevent loading ActiveRecord models too early during the Rails boot process.However,
run_hooksin doorkeeper-openid_connect still calledDoorkeeper.config.access_grant_model.prependimmediately duringconfig.to_prepare, before ActiveRecord is fully initialized — causing:Changes
lib/doorkeeper/openid_connect/orm/active_record.rbWraps the
access_grant_model.prependandestablish_connectionlogic insideActiveSupport.on_load(:active_record)in therun_hooksmethod, matching the pattern already used ininitialize_models!and in doorkeeper's own updatedinitialize_configured_associations.The existing version check is preserved:
Doorkeeper.config.access_grant_model(the new configurable model API)Doorkeeper::AccessGrantdirectly