1.32.0 also introduced an incompatibility with Synapse modules that make use of `synapse.logging.context.LoggingContext`, such as [synapse-s3-storage-provider](https://github.com/matrix-org/synapse-s3-storage-provider).
This PR adds a note to the 1.32.0 changelog and upgrade notes about it.
===========================
This release fixes [a
regression](https://github.com/matrix-org/synapse/issues/9853)
in Synapse 1.32.0 that caused connected Prometheus instances to become
unstable. If you
ran Synapse 1.32.0 with Prometheus metrics, first upgrade to Synapse
1.32.1 and follow
[these
instructions](https://github.com/matrix-org/synapse/pull/9854#issuecomment-823472183)
to clean up any excess writeahead logs.
Bugfixes
--------
- Fix a regression in Synapse 1.32.0 which caused Synapse to report
large numbers of Prometheus time series, potentially overwhelming
Prometheus instances.
([\#9854](https://github.com/matrix-org/synapse/issues/9854))
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEgQG31Z317NrSMt0QiISIDS7+X/QFAmCALNwTHGFuZHJld0Bh
bW9yZ2FuLnh5egAKCRCIhIgNLv5f9CLbEADBxSsZZkemuPTyRiyDOMCeElLraeAF
xqTNG2II2u38kFPvZoyQDztw0Qblu5ErEvRDM7P3jCH+CKNS1A4GLeuroDx0AeGH
ieDTBs9lkJ9/Omi8SC6TuDz1ywURXaU5uk3Uuo05WCnambSathmOkfkM9vO2UnsT
KUpx9dgW48nkYv8/ynhUMVj7cypIRwvWDzQc9LkomZQaqqHmDFBry6wlytKNtOah
KVBzZkFq4/R+QjEqhO5zU2TkdfExwNbNzQ9ZgyRGHjWkAWQEA9CO3WGCms3QyuDX
EX2FooLOZ+Q1GZ1VlOcsDuOt5YAIlxpdxFkApKfN6sO4rDDxLdY7du0fMzrEOUvp
SX3g1bITAGa6NYQm+ACZJwKizHu9oxo9aSh59DoLHMzuDFLkjLirW+dNwN9xFyDo
J5imJUe6T3KGkZgH8UJDiWYuTzw8PzObRjLL0cjAAa8S0bf3VJ1t4UkhGlip9/LR
xOvuo9pdUD6rquy9tVzIKxtg2MgyjyuRT2+C9GllvYHqqUV2UBDTGkOCT/uWCYfG
IdxMf5IQEfATkRCzdFQ6Sh0v+GWkfzBNTy6sv8+JJmHAV9uoTC1jRXR9f1Kzd8H4
RPnjQyKoNxVhA/f7pmv5XFNUM4UNZ0I7HX6I5mZTYjqr+xwqOthwnNnKU/DagxKq
DypHBY8rq+dJRA==
=olOn
-----END PGP SIGNATURE-----
Merge tag 'v1.32.1'
Synapse 1.32.1 (2021-04-21)
===========================
This release fixes [a regression](https://github.com/matrix-org/synapse/issues/9853) in Synapse 1.32.0 that caused connected Prometheus instances to become unstable. If you ran Synapse 1.32.0 with Prometheus metrics, first upgrade to Synapse 1.32.1 and follow [these instructions](https://github.com/matrix-org/synapse/pull/9854#issuecomment-823472183) to clean up any excess writeahead logs.
Bugfixes
--------
- Fix a regression in Synapse 1.32.0 which caused Synapse to report large numbers of Prometheus time series, potentially overwhelming Prometheus instances. ([\#9854](https://github.com/matrix-org/synapse/issues/9854))
As far as I can tell our logging contexts are meant to log the request ID, or sometimes the request ID followed by a suffix (this is generally stored in the name field of LoggingContext). There's also code to log the name@memory location, but I'm not sure this is ever used.
This simplifies the code paths to require every logging context to have a name and use that in logging. For sub-contexts (created via nested_logging_contexts, defer_to_threadpool, Measure) we use the current context's str (which becomes their name or the string "sentinel") and then potentially modify that (e.g. add a suffix).
This attempts to be a direct port of https://github.com/matrix-org/synapse-dinsic/pull/74 to mainline. There was some fiddling required to deal with the changes that have been made to mainline since (mainly dealing with the split of `RegistrationWorkerStore` from `RegistrationStore`, and the changes made to `self.make_request` in test code).
When receiving a /send_join request for a room with join rules set to 'restricted',
check if the user is a member of the spaces defined in the 'allow' key of the join
rules.
This only applies to an experimental room version, as defined in MSC3083.
This basically speeds up federation by "squeezing" each individual dual database call (to destinations and destination_rooms), which previously happened per every event, into one call for an entire batch (100 max).
Signed-off-by: Jonathan de Jong <jonathan@automatia.nl>
Part of #9744
Removes all redundant `# -*- coding: utf-8 -*-` lines from files, as python 3 automatically reads source code as utf-8 now.
`Signed-off-by: Jonathan de Jong <jonathan@automatia.nl>`
This PR adds a Dockerfile and some supporting files to the `docker/` directory. The Dockerfile's intention is to spin up a container with:
* A Synapse main process.
* Any desired worker processes, defined by a `SYNAPSE_WORKERS` environment variable supplied at runtime.
* A redis for worker communication.
* A nginx for routing traffic.
* A supervisord to start all worker processes and monitor them if any go down.
Note that **this is not currently intended to be used in production**. If you'd like to use Synapse workers with Docker, instead make use of the official image, with one worker per container. The purpose of this dockerfile is currently to allow testing Synapse in worker mode with the [Complement](https://github.com/matrix-org/complement/) test suite.
`configure_workers_and_start.py` is where most of the magic happens in this PR. It reads from environment variables (documented in the file) and creates all necessary config files for the processes. It is the entrypoint of the Dockerfile, and thus is run any time the docker container is spun up, recreating all config files in case you want to use a different set of workers. One can specify which workers they'd like to use by setting the `SYNAPSE_WORKERS` environment variable (as a comma-separated list of arbitrary worker names) or by setting it to `*` for all worker processes. We will be using the latter in CI.
Huge thanks to @MatMaul for helping get this all working 🎉 This PR is paired with its equivalent on the Complement side: https://github.com/matrix-org/complement/pull/62.
Note, for the purpose of testing this PR before it's merged: You'll need to (re)build the base Synapse docker image for everything to work (`matrixdotorg/synapse:latest`). Then build the worker-based docker image on top (`matrixdotorg/synapse:workers`).
Context is in https://github.com/matrix-org/synapse/issues/9764#issuecomment-818615894.
I struggled to find a more official link for this. The problem occurs when using WSL1 instead of WSL2, which some Windows platforms (at least Server 2019) still don't have. Docker have updated their documentation to paint a much happier picture now given WSL2's support.
The last sentence here can probably be removed once WSL1 is no longer around... though that will likely not be for a very long time.
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
Andrew Morgan