Enable the Mongoid 9 defaults

Why

#881 upgraded the gem but deliberately left the feature flags on their 8.1 values — its own scope notes said "Consider landing the gem bump on 8.1 first and flipping defaults in a follow-up commit," and #892 did exactly that. config/initializers/mongoid.rb still reads:

Mongoid.configure do |config|
  config.load_defaults 8.1
end

That was the right call: it made the gem bump behaviour-preserving, so a failure there was unambiguously the gem and not a flag. But it means the flip is still outstanding and, with #881 closed, currently unowned. This issue tracks it, mirroring #884 and #887 for the Rails framework defaults.

Note the gem landed on 9.0.11, not the 9.1 named in #881. Irrelevant here — load_defaults 9.0 is the target either way.

What actually changes

Mongoid::Config::Defaults#load_defaults (lib/mongoid/config/defaults.rb) shows 8.1 setting exactly four flags to legacy values before falling through to 9.0, which is itself a no-op ("All flag defaults currently reflect 9.0 behavior"). So the flip is precisely these four:

Flag	Now (8.1)	After (9.0)	Applies to this app?
immutable_ids	false	true	Yes — one call site, see below
legacy_persistence_context_behavior	true	false	No — no .with(...) usage anywhere in app/ or lib/
around_callbacks_for_embeds	true	false	No — app has zero embedded associations
prevent_multiple_calls_of_embedded_callbacks	false	true	No — same reason

Two of the four concern embedded associations, and this app has no embeds_many / embeds_one / embedded_in (confirmed by grep across app/ and lib/; Checkin uses has_many with class_name: "Checkin::Treatment" and friends). A third has no call sites. So the real surface is one flag.

The one thing to check: immutable_ids

Under the 9.0 default, enforce_immutability_of_id_field! (lib/mongoid/persistable/updatable.rb:194) raises Mongoid::Errors::ImmutableAttribute instead of warning:

if _id_changed? && !_id_was.nil? && persisted?
  if Mongoid::Config.immutable_ids
    raise Errors::ImmutableAttribute.new(:_id, _id)
  else
    Mongoid::Warnings.warn_mutable_ids
  end
end

There is exactly one place in the app that mutates _id on a persisted document — app/controllers/api/v1/reactions_controller.rb:47:

reaction.id = params[:id] if params[:id].present?

render json: serialized_reaction(reaction), status: :created

Reaction is a Mongoid::Document, and this runs after the record has been saved, apparently to echo a client-supplied id back in the response body.

It may well be fine. That check runs during a persistence operation, and here the assignment is followed only by serialization, with no subsequent save — so the raise may never trigger. But it is the one line in the codebase that can hit this flag, it sits in an API response path, and the controller specs should be pointed at it explicitly rather than relied on incidentally. Verify, do not assume.

Scope

• Flip config.load_defaults 8.1 -> 9.0 in config/initializers/mongoid.rb
• Exercise reactions_controller create specifically, including the params[:id].present? branch, and confirm the serialized response shape is unchanged
• Confirm no Mongoid::Warnings output disappears in a way that indicates behaviour changed rather than a warning being retired

Deploy-ordering note: unlike the Rails defaults flips in #884/#887, none of these four flags change an on-disk or wire format, so this does not need to be held back from the deploy that carries it. Worth re-confirming against the Mongoid changelog before merging.

Acceptance criteria

• config.load_defaults 9.0 in config/initializers/mongoid.rb
• Full suite green
• reactions_controller#create verified against immutable_ids = true, including the client-supplied-id branch
• API response ID formatting unchanged (the BSON::ObjectId to_json/as_json patch in the same initializer still governs every ID in every response)

Related

Follow-up to #881 / #892. Independent of the Rails sequence — it can land at any point and does not block or depend on #883.

---

Part of the Ruby + Rails upgrade sequence. Ruby 3.2 reached end of life on 2026-04-01 and the backend is on Rails 7.1; the goal is Ruby 3.4.10 and Rails 8.1, in steps that each keep CI green and are independently deployable.

🤖 Generated with Claude Code

Read config/initializers/mongoid.rb alongside lib/mongoid/config/defaults.rb, then run the reactions_controller specs, focusing on reactions_controller#create and its client-supplied-id branch. Verify the serialized response shape and ID formatting remain unchanged with the 9.0 defaults, then run the full suite. Done means the initializer uses 9.0 and all acceptance criteria pass without unexplained behavior changes.