Discourse の通知 API およびデータエクスプローラークエリを使用しており、以下の通知の統合・グループ化動作が観測されています：
- 返信・コメント通知（
notification_type = 2） - リアクション通知（
notification_type = 25）
観測された動作
- 短い時間内に同じトピック・投稿に対して 2 つの返信・コメントがあっただけでも、通知が統合・グループ化されています。
- 2 番目のアクションに対して、常に個別の通知行が作成されるわけではありません。
- 既存の通知行が更新・置換され、新しい行が挿入されるように見えます。
- 古い通知行が
notificationsテーブルから消えることがあります。 - リアクション通知も同様に統合されているように見えます。
- UI には「2 件の返信」などのグループ化されたカウントが表示される一方、データベース/API 側では単一の通知行しか反映されていない場合があります。
以下の設定が見つかりました：
linked notifications consolidation window minslikes notification consolidation window minsnotification_consolidation_threshold
質問
- これらの設定は UI のグループ化のみに関連するものでしょうか、それともデータベース/API レベルの通知統合も制御するのでしょうか？
- 2 つのアクションでも通知が統合される場合、Discourse は統合しきい値に達する前に既存の通知行を内部的に再利用・更新しているのでしょうか？
- 各返信・リアクションが個別の通知レコードを作成するように、通知統合を完全に無効化するサポートされた方法はありますか？
notificationsテーブルは、リンクされた通知やリアクション通知に対して意図的に「追加専用」ではないように設計されているのでしょうか？- リアクション通知（
notification_type = 25）において、通知ペイロード/API から反応したユーザーを確実に特定できるサポートされた方法はありますか？
主に、通知システムの意図された動作を理解し、完全に独立したアクションごとの通知がサポートされているかどうかを確認しようとしています。