-
Notifications
You must be signed in to change notification settings - Fork 33
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
synapse_auto_compressor panics on start after using the history delete api to remove remote events #78
Comments
Could you run this with the environment variable |
While I would love to it seems that is all I am getting even with the env variable set and in a debug binary:
|
Thanks for trying that---I wonder what's happened there? |
I'm not sure if this is helpful, but deleting the relevant room entries into state_compressor_state and state_compressor_progress. At least made the auto compressor resume working for me. |
By the way I now tried the workaround of deleting it from the table. However that just makes it fail on missing some other position :/ Also I now know that for me the affected room is TWIM |
Anytime that happens just repeat the previous step to delete references of the room from both tables and the compressor will resume. You may have to do that multiple times. |
Yeah but thats kinda annoying to do on an automated setup :) I will instead now have a look at a) changing to logging to get useful backtraces and b) take a look at handling this or atleast do the cleanup automatically instead of doing a panic here. :) |
This comment was marked as outdated.
This comment was marked as outdated.
(See hidden comment for minor more info) Proper debug stack on where it crashes:
This is using this forked version (replacing the logging functions mainly: https://github.com/MTRNord/rust-synapse-compress-state/tree/95206e295599973bc676c32ec4639852830ef4c0 ) |
Also, MTRNord@940aba6 contains experimental error handling for this. It will essentially just skip the room in case of this error entirely. It won't do any cleanup currently, but at least not panic. Furthermore, it's not tested and potentially breaking stuff at this time. Hence, the warning below. The potentially incorrect and problematic changes are here: MTRNord@940aba6#diff-aecc1fa342e82a5188eb5d3fce02ecc1adc1c82ae413ed814a6f9f362d5cba55R229-R236 As I am not sure if it is safe to break there. DO NOT USE THE ABOVE COMMIT! (It may very well break your synapse as it changes stuff in the actual logic of the algo)Edit: There indeed was a bug, and it still would have committed the new (now broken) state to the db. This is fixed in MTRNord@427a37f Edit: Initial testing seems to be working after some choking:
It now just prints the error and not modifies the state for that room. |
I just ran into the same Issue. Where the Compressor fails on a Room that got purged in the Past:
|
I'm always calling the following script in preparation of a compressor run:
|
@FrankNagel running this script fixes my issues |
It would be great if this could be incorporated into this program, as a nice simple way to do this recovery after a purge. |
Is there any plans to tackle this issue? It seems like a major usability bug to me that the tool always crashes after a room has been deleted. We ran into the same issues and #78 (comment) indeed fixes the issue (until next time a room got deleted). |
Describe the bug
To Reproduce
Steps to reproduce the behavior:
purge_history
on a roomExpected behavior
It runs or atleast ignores the invalid rooms
The text was updated successfully, but these errors were encountered: