Skip to content
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

Store configuration to disk or elsewhere reliable / Matrix state resets keep altering configuration and banning benevolent users for "spam" #196

Closed
Mikaela opened this issue Jan 4, 2024 · 5 comments
Labels
bug Something isn't working enhancement New feature or request L3 Some Users Likelihood P3 Outrageous / Cannot continue to or start to use Priority level - includes missing documentation leading to same outrage etc T5 Major usability Impairs usability in key scenarios.

Comments

@Mikaela
Copy link
Member

Mikaela commented Jan 4, 2024

I have three times disabled basicfloodingprotection as it keeps triggering on redactions or other expected Matrix behaviour (#187), but the change gets reverted as Matrix cannot be trusted for things such as software configuration.

Thus I think the configuration should be stored on disk or something like software usually does.

Ref: matrix-org/synapse#8629

@Mikaela Mikaela added bug Something isn't working enhancement New feature or request L3 Some Users Likelihood P3 Outrageous / Cannot continue to or start to use Priority level - includes missing documentation leading to same outrage etc T5 Major usability Impairs usability in key scenarios. labels Jan 4, 2024
@Gnuxie
Copy link
Member

Gnuxie commented Jan 21, 2024

This doesn't seem to be caused by state resets, since the list of enabled protections is loaded from account data. However this is still a Major usability issue.

@Mikaela
Copy link
Member Author

Mikaela commented Jan 28, 2024

And this happens again. Were there any ideas on what causes it, if not state resets?


#196 - is it possible that Draupnir isn't either writing or reading to/from account data? I think Draupnir4all was rebooted a couple of times yesterday or two days ago or so and I wonder if that is relevant to it happening again.

However it's a couple of hours since so-called flooder went to sleep so I don't know if that is relevant as the "state reset" seems to have happened long after the spam. I don't know if @MTRNord has some automatic that would trigger around this time to cause this.

My other idea was automatic message removal, but reacting configuration changes after message redaction would be stupid in my opinion and the timing doesn't match since I haven't booted computer (and thus Nheko) yet today, so I haven't removed any messages automatically either.

  • Me at Draupnir room on Matrix in case any of this proves itself relevant.

@Gnuxie
Copy link
Member

Gnuxie commented Jan 28, 2024

To be confirmed, but we suspect that under certain conditions where synapse starts and then later loses a connection to the database, it will return empty account data (or something else TBC) with a http OK response to Draupnir when requested. Meaning that we have no way to detect this failure mode, and Draupnir is then using the defaults for enabled protections.

@Gnuxie
Copy link
Member

Gnuxie commented Jan 28, 2024

OK turns out there was a Synapse+Redis problem specific to draupnir.midnightthoughts.space CC @MTRNord will close on confirmation.

@MTRNord
Copy link
Collaborator

MTRNord commented Jan 30, 2024

I am monitoring this but it seems to have been resolved after the redis was fixed. Closing :)

@MTRNord MTRNord closed this as completed Jan 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request L3 Some Users Likelihood P3 Outrageous / Cannot continue to or start to use Priority level - includes missing documentation leading to same outrage etc T5 Major usability Impairs usability in key scenarios.
Projects
None yet
Development

No branches or pull requests

3 participants