I don't really remember why this was so complicated; I think it dates
back to the time when we had to instantiate the Config classes before
we could call `add_arguments` - ie before #5597. In any case, I don't
think there's a good reason for it any more, and the impact of it
being complicated is that `--help` doesn't work correctly.
We pass --daemonize on the commandline, which (since at least #4853) overrides
whatever the config file, so there is no need for it to be set in the config
file.
`REPLICATE` is now a valid command, and it's nice if you can issue it from the
console without remembering to call it `REPLICATE ` with a trailing space.
Separate `SimpleCommand` from `Command`, so that things which don't want to use
the `data` property don't have to, and thus fix the warnings PyCharm was giving
me about not calling `__init__` in the base class.
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.
===========================
- Remove the the pin to Pillow 7.0 which was introduced in Synapse 1.12.2, and
correctly fix the issue with building the Debian packages. ([\#7212](https://github.com/matrix-org/synapse/issues/7212))
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEv27Axt/F4vrTL/8QOSor00I9eP8FAl6HCicACgkQOSor00I9
eP+TYgf+P5+hlfR1xiYt8R+qzT2YIyBmYa6eGT8QoHMQx3ndMuYF2rCm/7i6JVVO
+40kXIkRwRyge9dQIPaFNiWWGVQTMPROkLqB1Wo4CBK2fDLGqh2mEoqkS/65ZYFX
8ktaB0i/iyhUQg6KQCQ701mLydikh3Lr+a2RnezWa8xGJpBFdA/MYYf+O5reiorg
LeKyEgxVOBbURxFPNBV+eBv9+/bUYUIV+TijXK+n+mywsYa5MQpPKFWK6NzCR3O9
7LqW0lInkKeZjusUZNZuuFYtbZqKiqQKomCAxyOCiUKerENXrCXxfKLrDSVlc7l+
doyZEZA8uNXpiz7CF5DNrheEOxDzzQ==
=ZWNz
-----END PGP SIGNATURE-----
Merge tag 'v1.12.3'
Synapse 1.12.3 (2020-04-03)
===========================
- Remove the the pin to Pillow 7.0 which was introduced in Synapse 1.12.2, and
correctly fix the issue with building the Debian packages. ([\#7212](https://github.com/matrix-org/synapse/issues/7212))
===========================
This release fixes [an
issue](https://github.com/matrix-org/synapse/issues/7208) with building the
debian packages.
No other significant changes since 1.12.1.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEgQG31Z317NrSMt0QiISIDS7+X/QFAl6GKjQTHGFuZHJld0Bh
bW9yZ2FuLnh5egAKCRCIhIgNLv5f9IDlD/4901bArTyjasnD3tvbaf3N4Z8oatPu
bSn2AZv9rnhiPjqLnqs4EWkFihRbOe2jM3DQ/j2h8LTxBSSTxUY8LQHi94PtcMFc
o2Fj6Bd8UOLJPep5xdGbEOlgeqTkAxiMQpghNFP5ptmLEba7OdHDugJaF6yLDdSW
TtX6W9PAukHuP49EvUMdfORBGLxC9nyUU0uIha0iuDZBsV/MRmlDQVhQ2UTZY9NU
ayiEvgHH0jVw7Hy3O7kI8dFuvgAVIqefYdZnwdB71zgujNQs+/IJQnTdcCwc/qFB
2DnJqQRJDQ5fB0IfE3uG+24vTwNx6yKwGETENIMUd1mhlh9nX9Jx66zlEjeupA2Q
G0UxUVWLYpboP94cMI4voxpq0SM3DtJP0fZRiGkId3njjv4icIX7nqUeasF5MkVC
i7/6OOIAYpLekmyVVsN/gyYA1W59Kr/rEyi29lThzdAwnFwZOnW2QvEjaERPQ91t
aQJ0n92SkMW14MY2JEcu5dHSI806eFGAPJoiWFk/O/2ez2Lt3dnCjfx/DZwEvuAx
OyFsEnLWAaJsx7rYIinoHH5zepI2ixk0PyE1IbyZyoVnUqlDsi7nl4w4ynhMu6F2
OjyJgI2qiNqnTJFpYaHDpFqrZK6TSm1oyQOWZlHCj79YoqC7IigZzrKzgjS4A2d0
qzgHVUxnivf5kA==
=Uerf
-----END PGP SIGNATURE-----
Merge tag 'v1.12.2'
Synapse 1.12.2 (2020-04-02)
===========================
This release fixes [an
issue](https://github.com/matrix-org/synapse/issues/7208) with building the
debian packages.
No other significant changes since 1.12.1.
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.
