dendrite/userapi/consumers
texuf 46f0ed379a Hack out read receipt de-duping protection
zion hack - always send the notification data on a read receipt
the notifications are stored in two different databases, and somehow the notification database
prunes data, so trying to mark old notifications as read will fail, but the notification will still exist in the other db
todo, revist when this refactor lands: https://github.com/matrix-org/dendrite/pull/2688/files

 it looks like we cleanup the notification table after a day

func (s *notificationsStatements) Clean(ctx context.Context, txn *sql.Tx) error {
	_, err := sqlutil.TxStmt(txn, s.cleanNotificationsStmt).ExecContext(
		ctx,
		time.Now().AddDate(0, 0, -1).UnixNano()/int64(time.Millisecond), // keep non-highlights for a day
		time.Now().AddDate(0, -1, 0).UnixNano()/int64(time.Millisecond), // keep highlights for a month
	)
	return err
}
But we don't clean up the notifications in the syncAPI table.

When we send a read receipt we first do a updated _, err := s.db.SetNotificationsRead(ctx, localpart, roomID, int64(read.Read), true) and only forward the message on if the table was updated. If a user waits more than a day to send a read receipt, they can't clear their notifications.
2022-09-15 10:33:39 -07:00
..
syncapi_readupdate.go Hack out read receipt de-duping protection 2022-09-15 10:33:39 -07:00
syncapi_streamevent.go Update getting pushrules, add tests, tweak pushrules (#2705) 2022-09-09 13:56:33 +02:00
syncapi_streamevent_test.go Update getting pushrules, add tests, tweak pushrules (#2705) 2022-09-09 13:56:33 +02:00