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
notificationstable. -
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
-
Are these settings only related to UI grouping, or do they also control database/API-level notification consolidation?
-
Since notifications are getting consolidated even with only 2 actions, does Discourse internally reuse/update existing notification rows before the consolidation threshold is reached?
-
Is there any supported way to disable notification consolidation entirely so every reply/reaction creates a separate notification record?
-
Is the
notificationstable intentionally designed to be non-append-only for linked/reaction notifications? -
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.