So as a history lesson.
The Matrix Bot SDK uses the npm library "requests".
When there was a http error, matrix-bot-sdk
would literally throw the response object.
This would be a horrible 1000+line long thing to accidentally
be logged to the console via node's inspect.
Though it was inevitable since you can't be sure every catch
was handling the error correctly. Irregardless, the solution
developed at Element was to create an error object
that had concise details.
This was great, however, within the matrix-bot-sdk there is
[this](https://github.com/Half-Shot/matrix-bot-sdk/blob/f58d7ea6e24d1db8b9b8009dea4cd97cbff54d0c/src/http.ts#L66)
awful line of code which logs every http error as error using the
matrix-bot-sdk logger.
This wastes so much log space and causes alarm fatigue,
rather than muting the module, the action instead taken
was to redact stack traces from http errors.
This was not a good idea.
Eventually matrix-bot-sdk was updated to have a MatrixError type
when a request was performed via the client-server api that had an
error.
matrix-appservice-bridge depends upon this and so Mjolnir now needs
to be updated to throw MatrixError's.
We have gone a step further in this commit and also muted
the matrix-bot-sdk http module, to stop the alarm fatigue problem
https://github.com/turt2live/matrix-bot-sdk/pull/158
We haven't changed this yet and I'd like to merge the current changes
to the new command framework before we go to town changing all the legacy commands.
Yes a test should probably be written for this, even if just as a debug
utility. This test just wasn't testing much regardless and
time needs to be put aside to do it properly.
The feature is still under development though.
They're required which is bs because people are just going to make
up bullshit to satisfy the requirement. And it's rare
that they need to be intercepted.
What's rarer is intercepting them and not being able to change
the implementation.
So what am i going to do instead?
just not have it and you can subtype CommandError.
until i can think of something else.
This commit is NOT contributed under the Apache-2.0 License.
Copyright (C) 2022 Gnuxie <Gnuxie@protonmail.com>
All rights reserved.
we need it for more than validation
probably considering getting rid of the error code thing
or making it optional idk.
This commit is NOT contributed under the Apache-2.0 License.
Copyright (C) 2022 Gnuxie <Gnuxie@protonmail.com>
All rights reserved.
We've basically made an embedded mini language for commands.
The idea is that there are a sequence of strings at the start
of a command that are pattern matched against a table.
Then eventually we will also pattern match against the presentation
types that they each accept.
This commit is NOT contributed under the Apache-2.0 License.
Copyright (C) 2022 Gnuxie <Gnuxie@protonmail.com>
All rights reserved.
While this isn't a true presentation style interface,
the idea is that there is an argument stream to commands
that we pattern match commands against, and there are
different mediums that the commands can be invoked from.
There are translators between presentation types
and also between commands and mediums to do things like
render the result of the command for Matrix etc.
This is all inspired by the Common Lisp Interface Manager (CLIM).
But there are significant differences since, hello, this is
essentially being made for Matrix bots and appservices.
This commit is NOT contributed under the Apache-2.0 License.
Copyright (C) 2022 Gnuxie <Gnuxie@protonmail.com>
All rights reserved.
This will want splitting out for other matrix bots to use eventually.
MatrixInterfaceCommand needs decoupling from Mjolnir and then it will
be added too.
I'm deciding that we can now go ahead and use the new parts in
the appservice bot.
The reason being that the syntax of old commands
has optional arguments bang in the middle of
the argument list.
Which makes validating and parsing the argument list (not just from
a string, but also from the result of the CommandReader) really hard
and special cased.
When this command does get refactored, the syntax will change.
The idea is that the reader allows us to parse commands into
concrete types that will help us destructure/pattern match
against them later on.
This commit is NOT contributed under the Apache-2.0 License.
Copyright (C) 2022 Gnuxie <Gnuxie@protonmail.com>
All rights reserved.
This started out as just a way to find out why mjolnir was syncing with lists several times for each update to a policy list.
The main changes are
- Verbosity was irrelevant to the sync command but for some reason was an option.
Unfortunately all this did was suppress whether to tell you when it had finished, meaning it wouldn't
when verbose logging was disabled. Historically this was probably a parameter that got passed through
to applyServerAcl/applyUserBans, which can be horribly verbose, but they access the config directly.
- Stop emitting `'PolicyList.update'` when there are no changes.
- Include a revision ID for the `'PolicyList.update'`method and event.
- Use the revision ID in the `ProtectedRoomsSet` so that we don't unnecessarily resynchronize all rooms when the `'PolicyList.update'` event is received. Though not when the `sync` command is used. Since this is supposed to `sync` in the case when there is a state reset or otherwise or the user has changed some room settings.
- insert an await lock around the `PolicyList.update` method to avoid a race condition where a call can be started and finished within the extent of an existing call (via another task, this can happen if the server is slow with handling one request). `PolicyList.udpate` now has a helper that is synchronous to be called directly after requesting the room state. The reason for this is to enforce that no one `await`s while updating the policy list's cache of rules. Which is important because it is one of the biggest methods that I tolerate and visually checking for `await` is impossible.
- The revision ID uses a ULID, but this is unnecessary and could have just been a "dumb counter".
closes https://github.com/matrix-org/mjolnir/issues/447