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).
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
This change ensures that the appservice registration behaviour follows the spec. We decided to do this for Dendrite, so it made sense to also make a PR for synapse to correct the behaviour.
Related: #8334
Deprecated in: #9429 - Synapse 1.28.0 (2021-02-25)
`GET /_synapse/admin/v1/users/<user_id>` has no
- unit tests
- documentation
API in v2 is available (#5925 - 12/2019, v1.7.0).
API is misleading. It expects `user_id` and returns a list of all users.
Signed-off-by: Dirk Klimpel dirk@klimpel.org
We pull all destinations requiring catchup from the DB in batches.
However, if all those destinations get filtered out (due to the
federation sender being sharded), then the `last_processed` destination
doesn't get updated, and we keep requesting the same set repeatedly.
They don't make any sense on the intermediate builder image. The final
images needs them to be of use for anyone.
Signed-off-by: Johannes Wienke <languitar@semipol.de>
When joining 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 PR modifies `GaugeBucketCollector` to only report data once it has been updated, rather than initially reporting a value of 0. Fixes zero values being reported for some metrics on startup until a background job to update the metric's value runs later.
At the moment, if you'd like to share presence between local or remote users, those users must be sharing a room together. This isn't always the most convenient or useful situation though.
This PR adds a module to Synapse that will allow deployments to set up extra logic on where presence updates should be routed. The module must implement two methods, `get_users_for_states` and `get_interested_users`. These methods are given presence updates or user IDs and must return information that Synapse will use to grant passing presence updates around.
A method is additionally added to `ModuleApi` which allows triggering a set of users to receive the current, online presence information for all users they are considered interested in. This is the equivalent of that user receiving presence information during an initial sync.
The goal of this module is to be fairly generic and useful for a variety of applications, with hard requirements being:
* Sending state for a specific set or all known users to a defined set of local and remote users.
* The ability to trigger an initial sync for specific users, so they receive all current state.
