Notification are grouped for the more than 1 reply on the same post

We are using the Discourse notifications APIs/Data Explorer queries and are observing notification consolidation/grouping behavior for:

  • reply/comment notifications (notification_type = 2)

  • reaction notifications (notification_type = 25)

Observed Behavior

  • Even with only 2 replies/comments on the same topic/post within a short duration, notifications are getting consolidated/grouped.

  • Separate notification rows are not always created for the second action.

  • Existing notification rows appear to be updated/replaced instead of inserting new rows.

  • Older notification rows sometimes disappear from the notifications table.

  • Reaction notifications also appear consolidated similarly.

  • The UI may show grouped counts like “2 replies” while the database/API reflects only a single notification row.

We found these settings:

  • linked notifications consolidation window mins

  • likes notification consolidation window mins

  • notification_consolidation_threshold

Questions

  1. Are these settings only related to UI grouping, or do they also control database/API-level notification consolidation?

  2. Since notifications are getting consolidated even with only 2 actions, does Discourse internally reuse/update existing notification rows before the consolidation threshold is reached?

  3. Is there any supported way to disable notification consolidation entirely so every reply/reaction creates a separate notification record?

  4. Is the notifications table intentionally designed to be non-append-only for linked/reaction notifications?

  5. For reaction notifications (notification_type = 25), is there a reliable supported way to identify the reacting user from the notification payload/API?

We are mainly trying to understand the intended behavior of the notifications system and whether fully independent per-action notifications are supported.