Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Enable the Mongoid 9 defaults

未关闭
  • 哪里不对？
#904 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
76/100
Issue 类型
重构
描述清晰度
描述清楚
活跃度
活跃
技术栈
mongodb, rails, ruby
领域
api, backend, database

调研方向

阅读 config/initializers/mongoid.rb 和 lib/mongoid/config/defaults.rb，然后运行 reactions_controller specs，重点关注 reactions_controller#create 及其 client-supplied-id 分支。验证在 9.0 defaults 下，序列化响应的形状和 ID 格式保持不变，然后运行完整测试套件。完成的标准是 initializer 使用 9.0，且所有验收标准都通过，并且没有无法解释的行为变化。

由索引模型根据 Issue 内容生成。

描述

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

主要语言
Ruby
星标
50
派生
21
30 天内没有已合并 PR

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

rubyforgood/Flaredown 的其他 Issue

查看 rubyforgood/Flaredown 的全部 Issue

相似的 Issue

更多 Ruby Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。