matrix-org / matrix-org/mjolnir

Use an internal event bus/dispatcher?

Open
#608 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

T-Enhancement
Dominant language
TypeScript
Stars
445
Forks
75
Avg merge
2d 44m
Merged PRs (30d)
3

Description

This would be a pretty major refactoring, if not a rewrite. The [dispatcher pattern](https://medium.com/@kwindla/dispatcher-pattern-examples-c950c64440ee) would allow us to instrument the bot better and build more functionality around it. For example, if we wanted to add some code which monitors for spammy ban lists to take some other action, that code could simply attach itself to the dispatcher and do its thing.

The instrumentation benefits include improved logging (we can just dump the dispatcher to the log) and faster, more reliable, tests. [This test](https://github.com/matrix-org/mjolnir/pull/606/files#diff-116de74ab7c2801d8718c5c8256f269341490436ec03291d10151b8f9628b481) is an example of something which is already pretty close to using a dispatcher: it's relying on a signal from the event emitter to determine that an event was seen, but not redacted. If the protection in question simply did a `dispatcher.send("nsfw", eventId, {actioned: false})`, then the test could watch for that instead (and the runtime application logs would be clear that the event ID wasn't being processed for whatever reason).

A danger is everything connected to the dispatcher needs to be *fast* because while NodeJS can do async code, it's still a single thread. Element Web/Desktop has an internal dispatcher and occasionally spammy dispatches can slow down the whole application because it "wakes" every single listener.

Using a central event emitter as an event bus instead of a dispatcher could work to scope the dispatches to things that care, but can create a star-like call pattern instead of a bus pattern, which may be harder to debug/log when issues come up.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Begin with the test linked from pull request #606 and trace the event-emitter signal it observes. The issue does not name files or settle the dispatcher versus event-bus design; done would require an agreed architecture, migration scope, and tests or logging for the described signals.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
backend
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.