[Story] Safe Mode #1
Comments
|
This needs breaking up some more. We need to describe precisely how we will unify config in one model that requires a description object that describes with a JSON path where the value came from (as in the specific file, or MPS interface implementation, or a default). After this is done, the implication is that the old |
|
It should be noted that until we have #6 we will just have to disable all protections outright in safe mode. |
This was referenced Sep 13, 2024
Gnuxie
added a commit
to Gnuxie/matrix-protection-suite
that referenced
this issue
Sep 30, 2024
…ntConfigData` `PersistentConfigData` with recovery options for deserialization and usage errors. the-draupnir-project/planning#1
This was referenced Oct 7, 2024
|
Feedback:
|
Gnuxie
added a commit
to Gnuxie/matrix-protection-suite
that referenced
this issue
Nov 26, 2024
…n-settings When we decided to go with the config recovery in the safe mode work the-draupnir-project/planning#1, we also decided we would unify the wrappers used for all persistent config to be based on a system that leveraged TypeBox to provide us with schema. So this PR replaces `ProtectionSettings` with the new `ConfigDescription` system. This branch was written and linked with the work to migrate draupnir's protection's to the new system too. This slightly longer because the types are not liberal enough in what they accept when they are describing interfaces. This is a general bitch throughout the code base and I don't really know how to address it yet. Basically we need to allow interfaces for things like the methods on the `ConfigMirror` to accept arguments liberally. But the implementation needs to be as defensive as `unknown` etc. It's my fault for not really understanding variance properly. There was also an issue where the command reader from Draupnir's interface-manager produced objects that are different to the transform types in the `ConfigDescription` schema. So we had to update the `ConfigMirror` to accept serialized representations of values as a workaround. Not a big deal but it's a thing. Aside from that I've been at a low point these past weeks.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
A Draupnir moderator's Mjolnir fails to start due to a configuration issue. For example, sometimes it's not possible for the homeserver to find the room associated with a room reference in
org.matrix.mjonir.watched_listsand we have previously had to encourage them to manually login as the Mjolnir user, open devtools, and remove the reference from the event manually. This is obviously not something that is at all possible indraupnir4allor for a non technical user. Instead, Draupnir starts in a limited safe mode, and no protections are given any capabilities for consequences. The moderator is well aware that Draupnir is in safe mode and is notified about the source of the problem (e.g. watched lists config) even if an exact diagnosis cannot be given. The user should be able to use commands to edit the configuration in account data or room state without opening up devtools. After the configuration has been edited, the user should be able to restart the bot into the normal mode of operation by issuing a command.Acceptance Criteria
rooms removeorrooms add). Even if the exact reason for the config's failure to load is not diagnosable.Issues
ManagementRoomOutputneeds creating beforeDraupnirProtectedRoomSetor we need a log handler that reportswarnand above to management room Draupnir#338--draupnir-configargument, because the legacy modes of starting Draupnir without config are fragile. Draupnir#218Tasks
Dependencies
Total Pain
54
The text was updated successfully, but these errors were encountered: