Fix notification read and dismiss under Mongoid 9

[suttondemlong]

Fixes #908.

Marking a notification as read and dismissing one both raise on every request on master today. This is a regression from the Mongoid 8 → 9 upgrade in #892, not something waiting on the rest of the upgrade work, so it is worth taking on its own rather than behind anything else.

Two commits: the fix, then the spec that guards it.

The regression

NotificationsController#notification_params returns ActionController::Parameters, and update and destroy feed it straight into Notification.where(...). Parameters has not been a Hash since Rails 5; Mongoid 8 accepted it, Mongoid 9 requires a real Hash and raises:

Mongoid::Errors::InvalidQuery: Expression must be a Hash:
  #<ActionController::Parameters {"notificateable_id"=>"...", "notificateable_type"=>"Post", ...}>

In production ExceptionLogger's rescue_from "Exception" turns that into a 422 quoting a Mongoid internal error, which is likely why it has read as noise rather than as two broken endpoints. index is unaffected — it builds its own criteria.

The fix is to_h, which is safe because the parameters have already been through permit.

I audited app/ and lib/ for the same shape and this is the only Mongoid case. The others are Active Record or Active Model, which still accept permitted Parameters, or plain hashes built by hand — ReactionsController#reaction_params is the latter.

Two N+1s in the same controller

Not scope creep: config/environments/test.rb sets Bullet.raise = true, so these made the endpoint untestable. Any spec touching index died on UnoptimizedQueryError before reaching an assertion. Fixing them is what allowed the regression spec to exist at all.

• Notification's after_initialize :set_defaults recomputed post_id by reaching through notificateable on every instantiation — including records read back from the database that already had the value stored. One extra query per notification loaded, anywhere in the app, to recompute something it was already holding. Now guarded on post_id.blank?, which still backfills documents written before the field existed while costing nothing for the rest.
• The index aggregation titles each group through notificateable, so the query now eager loads it. Mongoid 9 does support includes for this polymorphic belongs_to; I checked before relying on it rather than assuming.

Verification

• 331 examples, 0 failures on this branch (324 on master, plus the 7 new ones), standardrb clean
• Reverting just the fix commit and re-running the new spec reproduces the bug: 5 failures, Mongoid::Errors::InvalidQuery on update and destroy, Bullet::Notification::UnoptimizedQueryError on index
• Branched from master, so it carries none of the in-flight upgrade work

Note on overlap

These same two commits also appear on the branch for #912, which is where they were found. They are cherry-picked here so this can merge first without waiting on that much larger review. Once this lands, #912 rebases and git drops the duplicates automatically.

Please rebase-and-merge or use a real merge commit — not squash, so the fix stays separable from its spec.

🤖 Generated with Claude Code