Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Enable the Mongoid 9 defaults

Abierto
  • ¿Algo no está bien?
#904 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
76/100
Tipo de issue
Refactorización
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
mongodb, rails, ruby
Área
api, backend, database

Línea de trabajo

Lee config/initializers/mongoid.rb junto con lib/mongoid/config/defaults.rb y luego ejecuta las specs de reactions_controller, centrándote en reactions_controller#create y su rama client-supplied-id. Verifica que la forma de la respuesta serializada y el formato del ID permanezcan sin cambios con los 9.0 defaults y luego ejecuta la suite completa. La tarea está terminada cuando el initializer usa 9.0 y todos los criterios de aceptación se cumplen sin cambios de comportamiento inexplicados.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Ruby
Estrellas
50
Forks
21
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rubyforgood/Flaredown

Todos los issues de rubyforgood/Flaredown

Issues similares

Más issues de Ruby

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.