| Commit message (Collapse) | Author | Files | Lines |
|---|
|
This completes the merging of server and client command processing.
|
|
|
|
|
|
public rooms list (#6899)
|
|
The aim here is to move the command handling out of the TCP protocol classes and to also merge the client and server command handling (so that we can reuse them for redis protocol). This PR simply moves the client paths to the new `ReplicationCommandHandler`, a future PR will move the server paths too.
|
|
Fixes #6815
Before figuring out whether we should alert a user on MAU, we call get_notice_room_for_user to get some info on the existing server notices room for this user. This function, if the room doesn't exist, creates it and invites the user in it. This means that, if we decide later that no server notice is needed, the user gets invited in a room with no message in it. This happens at every restart of the server, since the room ID returned by get_notice_room_for_user is cached.
This PR fixes that by moving the inviting bit to a dedicated function, that's only called when the server actually needs to send a notice to the user. A potential issue with this approach is that the room that's created by get_notice_room_for_user doesn't match how that same function looks for an existing room (i.e. it creates a room that doesn't have an invite or a join for the current user in it, so it could lead to a new room being created each time a user syncs), but I'm not sure this is a problem given it's cached until the server restarts, so that function won't run very often.
It also renames get_notice_room_for_user into get_or_create_notice_room_for_user to make what it does clearer.
|
|
|
|
Log warning when filesystem path is used.
Signed-off-by: Martin Milata <martin@martinmilata.cz>
|
|
|
|
|
|
Let's just call `getrusage` once on each logcontext change, rather than twice.
|
|
By running this stuff with `run_in_background`, it won't be correctly reported
against the relevant CPU usage stats.
Fixes #7202
|
|
matrix-org/babolivier/sso_whitelist_login_fallback""
This reverts commit 0122ef1037c8bfe826ea09d9fc7cd63fb9c59fd1.
|
|
This reverts commit 8d4cbdeaa9765ae0d87ec82b053f12ed8162f6f5.
|
|
matrix-org/babolivier/sso_whitelist_login_fallback"
This was incorrectly merged to master.
This reverts commit 319c41f573eb14a966367b60b2e6e93bf6b028d9, reversing
changes made to 229eb81498b0fe1da81e9b5b333a0285acde9446.
|
|
This was incorrectly merged to `master` instead of develop.
This reverts commit 90246344e340bce3417fb330da6be9338a701c5c.
|
|
|
|
|
|
|
|
Occasionally we could get a federation device list update transaction which
looked like:
```
[
{'edu_type': 'm.device_list_update', 'content': {'user_id': '@user:test', 'device_id': 'D2', 'prev_id': [], 'stream_id': 12, 'deleted': True}},
{'edu_type': 'm.device_list_update', 'content': {'user_id': '@user:test', 'device_id': 'D1', 'prev_id': [12], 'stream_id': 11, 'deleted': True}},
{'edu_type': 'm.device_list_update', 'content': {'user_id': '@user:test', 'device_id': 'D3', 'prev_id': [11], 'stream_id': 13, 'deleted': True}}
]
```
Having `stream_ids` which are lower than `prev_ids` looks odd. It might work
(I'm not actually sure), but in any case it doesn't seem like a reasonable
thing to expect other implementations to support.
|
|
|
|
|
|
|
|
|
|
|
|
|
