-
Notifications
You must be signed in to change notification settings - Fork 416
Clean up old device_federation_inbox rows
#18546
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
15d3027 to
dcf32ac
Compare
dcf32ac to
83870d2
Compare
4b46247 to
03bd0bd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's... never deleted currently ?? 🫣 🫣
I think the corresponding issue would more be #17370.
I am trying to grasp the potential consequences of ingesting the to_device EDUs several times. From my understanding of the code the to_devices would be delivered several times to the devices.
Is it fine ? If not, going from forever to a week seems a bit of a gap. If it is, we could perhaps just deliver several times, since it is covering an edge case and shouldn't happen that often (request would have go through but not the response).
We could also ditch device_federation_inbox altogether and keep idempotency if we add message_id to device_inbox.
Ah indeed, that was the issue I meant to link to 🤦
I think that can happen anyway? Though would also be happy increasing the delay to a month or whatever, this table isn't particularly large.
Unfortunately we delete things from |
Then perhaps ditching the table instead is better? better in the |
|
FTR I've checked internally with crypto team, and at least e2ee use cases will handle retransmission fine. |
|
For future reference: That work should fall under a different issue if it's deemed worth the effort. |
synapse/storage/schema/main/delta/92/06_device_federation_inbox_index.sql
Outdated
Show resolved
Hide resolved
|
|
||
|
|
||
| # How long to keep messages in the device federation inbox before deleting them. | ||
| DEVICE_FEDERATION_INBOX_CLEANUP_DELAY_MS = 7 * 24 * 60 * 60 * 1000 # 7 days |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably worth building these up to avoid mistakes and make it more clear using the constants
synapse/synapse/util/constants.py
Lines 15 to 20 in f500c7d
| # Time-based constants. | |
| # | |
| # Laying these out incrementally, even if only some are required, helps with | |
| # readability and catching bugs. | |
| ONE_MINUTE_SECONDS = 60 | |
| ONE_HOUR_SECONDS = 60 * ONE_MINUTE_SECONDS |
We will need a few more:
ONE_MINUTE_SECONDS = 60
ONE_HOUR_SECONDS = 60 * ONE_MINUTE_SECONDS
ONE_DAY_SECONDS = 24 * ONE_HOUR_SECONDS
MILLISECONDS_PER_SECOND = 1000| DEVICE_FEDERATION_INBOX_CLEANUP_DELAY_MS = 7 * 24 * 60 * 60 * 1000 # 7 days | |
| DEVICE_FEDERATION_INBOX_CLEANUP_DELAY_MS = 7 * ONE_DAY_SECONDS * MILLISECONDS_PER_SECOND |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like a new Duration class was added.
Are we going to remove the other constants?
synapse/synapse/util/constants.py
Lines 15 to 20 in f500c7d
| # Time-based constants. | |
| # | |
| # Laying these out incrementally, even if only some are required, helps with | |
| # readability and catching bugs. | |
| ONE_MINUTE_SECONDS = 60 | |
| ONE_HOUR_SECONDS = 60 * ONE_MINUTE_SECONDS |
How are we going to handle the seconds variation (vs MS)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@erikjohnston Still relevant ^
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we going to remove the other constants?
Yes, we probably should, but didn't want to do it here
How are we going to handle the seconds variation (vs MS)?
Generally we rarely operate in seconds, except at twisted boundaries. TBH I think its fine in those cases to just / 1000.
|
Hi, during my tests with 1.132.0 I found these errors logs, is this related? |
Fixes #17370