-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Appservice transaction IDs reset with sqlite3 #14556
Comments
Not sure what's going on here. We use a sequence generator synapse/synapse/storage/databases/main/appservice.py Lines 88 to 95 in aa70556
which on sqlite uses a synapse/synapse/storage/util/sequence.py Lines 276 to 279 in 51a5da7
which calls a synapse/synapse/storage/util/sequence.py Lines 204 to 224 in 51a5da7
That callback does lookup existing txns: synapse/synapse/storage/databases/main/appservice.py Lines 81 to 86 in aa70556
But we delete from that table when completing an AS transaction synapse/synapse/storage/databases/main/appservice.py Lines 311 to 331 in aa70556
so I think that catchup mechanism only works if you have outstanding transactions? |
This did indeed change in #12209: as of that change, we no longer persist the "last transaction ID" to the database, so if there are no pending transactions, then there is no way to figure out what ID we should start from. I vaguely remember being aware of it at the time, and concluding that the win in the common case of using postgres was worth it, versus the edge-case of trying to use appservices with sqlite. (see also #12209 (comment)). I guess a proper fix to this will need dedicated sqlite support. |
Description
When using a sqlite3 database, rebooting Synapse may cause it to reset its transaction ID count, meaning the IDs of future transactions will start from 1. This means existing appservices which use the transaction ID to deduplicate events may consider new transactions as ones they've seen before, until Synapse's transaction ID catches up to the most recent transaction ID that the appservice actually handled.
Steps to reproduce
Homeserver
Local testing homeserver
Synapse Version
v1.69.0
Installation Method
Other (please mention below)
Database
SQLite
Workers
Single process
Platform
Fedora Linux 37 (Workstation Edition), 64-bit
Configuration
Some experimental features:
Relevant log output
Anything else that would be useful to know?
last_txn
AS state #12209.The text was updated successfully, but these errors were encountered: