Warden::Proxy snapshots stale default_scope on first request after boot in Rails 8 dev (LazyRouteSet)

[ngan]

TL;DR

Rails 8's LazyRouteSet defers route loading until the first request. Devise sets warden_config.default_scope = :user from RouteSet#finalize!, but Warden::Proxy snapshots config at Proxy#initialize (@config = manager.config.dup) — so on the first request, the proxy holds a :default snapshot taken before Devise had a chance to set it. Any code that reads warden.session (no scope arg) raises Warden::NotAuthenticated: :default user is not logged in. PR #5728 makes Devise.mappings trigger route loading, but doesn't address the Proxy.dup timing — by the time anything calls Devise.mappings in the request flow, the proxy is already initialized.

Environment

• Devise 5.0.3 (also reproduces on main, since the relevant code is identical)
• Rails 8.0.5
• Warden 1.2.9
• Dev mode: config.eager_load = false, Rails.env.local? == true → Engine::LazyRouteSet is active

Reproduction

Any Rails 8 + Devise app where some code path reads warden.session without an explicit scope. Steps:

1. Stop the dev server.
2. Start bin/rails s.
3. With a valid Devise session cookie, request any authenticated page.
4. → Warden::NotAuthenticated: :default user is not logged in.
5. Refresh. → 200 OK.

The error message containing the literal symbol :default (rather than :user) is the giveaway.

Root cause

Boot-order regression introduced by Rails 8 LazyRouteSet

In railties-8.1.3/lib/rails/engine.rb:

initializer :make_routes_lazy, before: :bootstrap_hook do |app|
  config.route_set_class = LazyRouteSet if Rails.env.local?
end

Then in railties-8.1.3/lib/rails/application/finisher.rb, route eager-loading at boot is gated:

reloader.execute_unless_loaded if !app.routes.is_a?(Engine::LazyRouteSet) || app.config.eager_load

In dev: LazyRouteSet is in use and eager_load = false → both clauses false → routes are not loaded at boot. Devise's prepended RouteSet#finalize! (devise/lib/devise/rails/routes.rb) and Devise.configure_warden! therefore don't run until the first request hits the router (LazyRouteSet#call calls reload_routes_unless_loaded).

Warden::Proxy snapshots config too early

Warden::Manager#call creates a fresh Proxy per request, and Proxy#initialize snapshots the manager's config (warden/lib/warden/proxy.rb):

def initialize(env, manager)
  @manager, @config = manager, manager.config.dup
end

manager.config.dup creates a separate Hash. Subsequent mutations to manager.config don't propagate to the proxy.

The first-request-only asymmetry

Step	manager.config[:default_scope]	New Proxy.@config[:default_scope]
Boot complete	:default	n/a
Request 1 enters Warden middleware	:default	:default (snapshot)
Request 1 reaches LazyRouteSet#call → routes load → Devise.configure_warden!	mutated to :user	still :default
Request 1 hits anything that reads warden.session	:user	:default → raises NotAuthenticated
Request 2 enters Warden middleware	:user	:user (snapshot)
Request 2 hits the same code	:user	:user → works

That's why the bug only fires on the first request after boot.

Why PR #5728 doesn't fix it

#5728 made Devise.mappings call Rails.application.try(:reload_routes_unless_loaded). The chain does eventually trickle down to Devise.configure_warden! and mutate Warden::Manager#config[:default_scope]. But by the time anything in the request flow calls Devise.mappings (a controller, helper, route iteration, etc.), the Warden::Proxy has already been created with a snapshot of the stale config.

For #5728 to fix this, route loading would need to be triggered before Warden::Manager#call runs on the first request — or by middleware above Warden in the stack. Neither happens. We verified empirically: #5728 is in 5.0.3, and the bug still reproduces.

Suggested fixes

Three options, in order of preference:

Option A — assign default_scope (and other scope-independent keys) from an after_initialize hook

In Devise::Engine:

config.after_initialize do
  if Devise.warden_config
    Devise.warden_config.failure_app   ||= Devise::Delegator.new
    Devise.warden_config.default_scope ||= Devise.default_scope
    Devise.warden_config.intercept_401 = false unless Devise.warden_config.key?(:intercept_401)
  end
end

This runs after :build_middleware_stack (so Devise.warden_config is set) and before the server accepts requests. The per-mapping setup (serializers, scope_defaults) still happens from RouteSet#finalize! because it depends on Devise.mappings being populated, which only happens during route load.

Option B — split configure_warden! into a boot phase and a routes phase

Move scope-independent config (failure_app, default_scope, intercept_401) into a method invoked from after_initialize. Keep the per-mapping serializer/scope_defaults registration in the routes-finalize phase. Cleaner separation but a bigger refactor.

Option C — hook after_routes_loaded to mirror the existing before_eager_load

Devise already has before_eager_load { app.reload_routes! if Devise.reload_routes } which handles production. The symmetric fix for dev would be to also hook ActiveSupport.on_load(:after_routes_loaded) and invoke Devise.configure_warden! from there — though this still doesn't fix the very-first-request-after-boot case unless that hook fires before Warden middleware, which I don't believe it does.

Option A is the smallest, least invasive change that actually closes the timing window.

Workaround

Apps can mitigate locally by always passing an explicit scope: warden.session(:user) instead of warden.session. That's what we did in our codebase — but it's a sweep across every callsite, and any future bare warden.session reintroduces the bug.

Notes

• This isn't a hypothetical edge case: Devise's README and many Devise tutorials show warden.session[...] (no scope) in custom hook examples. Apps that copied that pattern silently break on Rails 8 dev.
• Pre-Rails-8 dev mode loaded routes at boot, so Devise has been silently relying on that timing. Rails 8's lazy routes broke an implicit contract.
• Happy to put up a PR for Option A if it's the direction you'd take.

[carlosantoniodasilva]

Thanks for the report.

I'm honestly wondering if we shouldn't just ditch lazy routes with Devise. It has always been the case that it needs routes eager loaded to initialize itself properly, mappings & etc, so maybe we should just enforce that and not use lazy routes.

Ref.: #5831
Possibly related: #5830

[andypike]

I came across this issue too when running specs. With the help of Claude, it created the following workaround that worked in our project. I'll post it here in case it's useful to others:

RSpec.configure do |config|
  config.before(:suite) do
    # Rails 8 uses LazyRouteSet, which defers route loading and finalization
    # (including `devise_for :users`) until the first HTTP request. Warden's
    # on_request test-mode callback fires at the START of that first request —
    # before Devise has drawn its routes or called configure_warden! — so
    # proxy.set_user stores the raw User object in the session rather than
    # Devise's expected [[id], salt] format, breaking session-based auth on
    # every subsequent request in the same example.
    #
    # Calling routes.finalize! directly is NOT sufficient: it sets the
    # @devise_finalized guard on the RouteSet before Devise.mappings is
    # populated, which prevents configure_warden! from running again when the
    # routes reloader later draws the routes properly.
    #
    # Instead, trigger the routes reloader directly. It draws routes first
    # (populating Devise.mappings) and then calls finalize! — so
    # configure_warden! runs with the correct mappings and user_serialize is
    # defined before any spec's first request.
    #
    # See: https://github.com/heartcombo/devise/issues/5844
    Rails.application.routes_reloader.execute_unless_loaded
  end
end

[carlosantoniodasilva]

@andypike thanks for the extra info.

If you have the opportunity, please give #5831 a try, to see if that also fixes the problem. I'm inclined to simply not use lazy routes for now in Devise if it does, to avoid other potential issues with it + Rails 8+

[albb0920]

I had this problem (ActionCable (re)connect before first HTTP request arrive, cause env["warden"].user to return nil because default scope is not set yet)
I can confirm #5831 works, and I think it's totally reasonable to disable lazy route set

[ngan]

we shouldn't just ditch lazy routes with Devise

I personally think not supporting lazy routes would be a bummer for large applications. Lazy routes shaves a good amount of time from our local development experience. That said, I don't know Devise well enough to suggestion a solution. Would it be possible to converse with Rails core/experts to see how they expected libraries like Devise to play nicely with Route lazy loading?

[chaadow]

I've opened waiting-for-dev/devise-jwt#284 which resembles what Option C is suggested by the PR's author ( after_routes_loaded )

and yeah I second what @ngan said, I maintain a large application with large routes, and lazy routes significantly improves app boot time in development

 initializer 'devise' do |app|
    config.after_routes_loaded do
       # devise code that needs routes loaded
   end
end

@carlosantoniodasilva In my humble opinion, I believe this is the most elegant solution that reconciles all worlds

[kaisq]

would it maybe be worth considering moving the devise_for declaration into the devise initializer? it would store any route generation code globally in the devise object (similar to the mappings, etc) and one could maybe even mount Devise in the routes file like any other engine? the mounting logic might need to be a little more fancy given that there can be multiple different mount points, but I think that would be achievable.