Sometimes we don't need exceptions to be reported on the error level.
This is especially true when the user does something out of order
and there's a permission error.
If we're aware of that possibility as developers and have accounted
for it, then it's unnecessary for it to be treated the same way
as a fatal error.
We also decided to log CommandExceptions and CommandErrors as
early as possible.
https://github.com/Gnuxie/Draupnir/pull/93/
We've done this to make the implementation a lot cleaner and
managable. However, we've taken the opportunity to simplify
all of the client code that would use this method.
Some of these simplifications might come at a small cost.
Updating server ACL, member bans and checking power levels
would all be clearly titled as seperate checks.
However, it should still be obvious what has gone wrong,
since any error would have to give a more detailed explanation.
And not everything is going to fail all at once (and if it does,
there are bigger issues).
a lot cleaner
https://github.com/Gnuxie/Draupnir/pull/85
A bizarre contraption.
The ErrorCache was seemingly introduced to reduce the number of errors
in the management room.
https://github.com/matrix-org/mjolnir/commit/82214c6cd88d83abed05fec4a871a874e6e0265b
It makes sense why it was added if you consider that many admins
will run Draupnir without giving it the permission to manage server
ACL in its rooms. Though, I'm not sure why then you would add the error
cache rather than properly supporting that use case.
So perhaps there were other reasons.
Either way, what is drawing the line for me is that the ErrorCache
will suppress any error within rooms that is not a permission error,
if there was any error that was not a permission error within a
15 minute window.
Considering the typical Draupnir will not even sync
for hours at a time, even in large communities.
It does present a problem for rooms with a lot of join/leave events.
I think that's probably why the error cache was added.
Ahh, well, fuck.
Well what is the real solution to this?
The real solution when the kind is acl is to allow the bot to run
without applying ACLs.
Ok fine but, hey wait a minute.
Why would there be any other kind of persistent error
when banning someone that would be unimportant enough to silently
hide in an ErrorCache??
IDK let's just add an opttion to disable server ACL,
since they might want to use another tool for that anyhow.
Out of scope for the current work though.
https://github.com/Gnuxie/Draupnir/pull/85
This adds the `displayname` command which just sets the displayname of the user.
-----
* Add command that allows to easily set the Displayname of a bot
* Only set the displayname once
* Add missing matrix interface adaptor and use CommandError
* Make displaynames with spaces work
This adds a `/healthz` endpoint to the appservice which allows this to work more nicely in kubernetes.
It also adds some metrics for tracking the provisioning state.
Grafana result:
Note: The ts-ignore are sadly required since the `_getValue` method is not public :/ I didnt find another solution apart from tracking it maybe elsewhere.
* Add health endpoint to appservice and add metrics via prometheus
* Ensure that we dont have duplicate metrics when the appservice is registered multiple times
* Move gauge modifications to utils function
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Fix typo
* Use the new help style on the appservice commands and add missing descriptions for the arguments
* Make the first letter of the table name uppercase in the help table
* .editorconfig: s/off/unset/g
This was breaking prettier and neovim as apparently off was invalid value
* .editorconfig: merge the two unset rule blocks
This was introduced in https://github.com/Gnuxie/Draupnir/pull/54/ (and therefore 1.83.0). Essentially we forgot to remove the room from the protected rooms set, when the remove command was used.
Ontop of this something to note is that during testing it is clear that the protected rooms set is loaded when configuring mjolnir, not when starting it. This is problematic as it means setup code in `fixtures.ts` does not actually wipe the protected rooms set.
This is actually really bad.
For multiple reasons.
The best way for this to be avoided is to drop everything
and reload it when the account data for watched lists is changed.
Then there isn't a situation where you have to inform anyone
about a change in what lists are being watched.
* Do not interrupt redact sequences due to error when backfilling
... Mainly timeouts.
* Change caught redaction error LogLevel from DEBUG to ERROR.
From matrix-org/mjolnir#479
---------
Co-authored-by: Marco Cirillo <marco.cirillo@aria-net.org>
Canonicalise the existence of the "admin room" for managing the appservice and Draupnir instances
* Add utilities for managing users in the admin room
* Merge the appservice admin room and access control list.
The majority of admins will need to use the draupnir admin commands
to manage the list.
* Utility methods for creating generic rules in PolicyLists.
* Commands for managing appservice users.
* Detail about important Draupnir concepts and context.
Stuff that is essential to understand if there's any hope of
maintaining this shit.
* Notes about the ban command.
* link to context in CONTRIBUTING.
* use matrix-appservice-bridge support for postgres
* upgrade matrix-appservice-bridge to include postgres fixes.
These are unreleased and a specific develop commit, but we're the only ones
who have made changes so far to the develop branch,
so should be fine.
* Upgrade matrix-appservice-bridge to 8.1.1.
8.0.1 was never added to npm for some weird reason.
Gnuxie