Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Enable the Mongoid 9 defaults

Aperta
  • Qualcosa non va?
#904 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
76/100
Tipo di issue
Refactoring
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
mongodb, rails, ruby
Ambito
api, backend, database

Direzione di ricerca

Leggi config/initializers/mongoid.rb insieme a lib/mongoid/config/defaults.rb, poi esegui le spec di reactions_controller, concentrandoti su reactions_controller#create e sul relativo ramo client-supplied-id. Verifica che la struttura della risposta serializzata e la formattazione dell’ID rimangano invariate con i 9.0 defaults, poi esegui l’intera suite. Il lavoro è completato quando l’initializer usa 9.0 e tutti i criteri di accettazione sono soddisfatti senza cambiamenti di comportamento non spiegati.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

type:infrastructure

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

Lingua principale
Ruby
Stelle
50
Fork
21
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rubyforgood/Flaredown

Tutte le issue di rubyforgood/Flaredown

Issue simili

Altre issue su Ruby

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.