* Fix presence timeouts when synchrotron restarts.
Handling timeouts would fail if there was an external process that had
timed out, e.g. a synchrotron restarting. This was due to a couple of
variable name typoes.
Fixes#3715.
=============================
Bugfixes
--------
- Fix bug where redacted events were sometimes incorrectly censored in the database, breaking APIs that attempted to fetch such events. ([\#6185](https://github.com/matrix-org/synapse/issues/6185), [5b0e9948](5b0e9948ea))
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEv27Axt/F4vrTL/8QOSor00I9eP8FAl2oj9sACgkQOSor00I9
eP+ZQQf9GQbjQhq92G1Mt1dI3HxXQnIvelGWaLC9rB++eGcafBkP0EJgCbQZTKda
WntghJib0oWVHVtPbwYKtwF3z365WbME3awO6RpRoMvrFL5PDqJ8Ma5LUgJ6/GuO
yDBfABbZk7PVS5WibftXXqibK8MkSrnId57VN3tc/SUHj3DGe4vk+A7plwjNckBj
2SLUA8DPw5I3Y4Z6peb6VweEA8M59+i3/0cZFAJ+4Ofy2Jad3z8kVXmJ1gTjBOdG
1bjBfnS2SrZLZwD79zJzaUR0zxfIvj62mL/fjrtR66oRmKF2T+9UnM7+9gH9JHWZ
ct3Mk4Nnr4VaBBWOWOcD2btvByckug==
=9lJk
-----END PGP SIGNATURE-----
Merge tag 'v1.4.1rc1' into develop
Synapse 1.4.1rc1 (2019-10-17)
=============================
Bugfixes
--------
- Fix bug where redacted events were sometimes incorrectly censored in the database, breaking APIs that attempted to fetch such events. ([\#6185](https://github.com/matrix-org/synapse/issues/6185), [5b0e9948](5b0e9948ea))
This fixed the weirdness of 400 vs 404 as http status code in the case
the filter id is not known by the server.
As e.g. matrix-js-sdk expects 404 to catch this situation this leads
to unwanted behaviour.
Hopefully this will fix the occasional failures we were seeing in the room directory.
The problem was that events are not necessarily persisted (and `current_state_delta_stream` updated) in the same order as their stream_id. So for instance current_state_delta 9 might be persisted *before* current_state_delta 8. Then, when the room stats saw stream_id 9, it assumed it had done everything up to 9, and never came back to do stream_id 8.
We can solve this easily by only processing up to the stream_id where we know all events have been persisted.
It turns out that _local_membership_update doesn't run when you join a new, remote room. It only runs if you're joining a room that your server already knows about. This would explain #4703 and #5295 and why the transfer would work in testing and some rooms, but not others. This would especially hit single-user homeservers.
The check has been moved to right after the room has been joined, and works much more reliably. (Though it may still be a bit awkward of a place).
More often than not passing bytes to `txn.execute` is a bug (where we
meant to pass a string) that just happens to work if `BYTEA_OUTPUT` is
set to `ESCAPE`. However, this is a bit of a footgun so we want to
instead error when this happens, and force using `bytearray` if we
actually want to use bytes.
