| Commit message (Collapse) | Author | Files | Lines |
|
Use Element CSS and logo in notification emails when app name is Element.
Signed-off-by: Jason Robinson <jasonr@matrix.org>
|
|
script (#7914)
Run `isort`, `flake8` and `black` over the `contrib/` directory and `synctl` script. The latter was already being done in CI, but now the linting script does it too.
Fixes https://github.com/matrix-org/synapse/issues/7910
|
|
|
|
|
|
|
|
The [postgres setup docs](https://github.com/matrix-org/synapse/blob/develop/docs/postgres.md#set-up-database) recommend setting up your database with user `synapse_user`.
However, uncommenting the postgres defaults in the sample config leave you with user `synapse`.
This PR switches the sample config to recommend `synapse_user`. Took a me a second to figure this out, so assume this will beneficial to others.
|
|
* Fix deprecation warnings due to invalid escape sequences.
* Add changelog
Signed-off-by: Karthikeyan Singaravelan <tir.karthi@gmail.com>
|
|
|
|
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
|
|
|
|
As mentioned in #7397, switching to a debian base should help with multi-arch work to save time on compiling. This is unashamedly based on #6373, but without the extra functionality. Switch python version back to generic 3.7 to always pull the latest. Essentially, keeping this as small as possible. The image is bigger though unfortunately.
|
|
It serves no purpose and updating everytime we write to the device inbox
stream means all such transactions will conflict, causing lots of
transaction failures and retries.
|
|
Fixes #7774
|
|
|
|
It's somewhat expected for us to have unknown room versions in the
database due to room version experiments.
|
|
|
|
|
|
|
|
|
|
objects. (#7849)
|
|
I'm pretty sure there's no technical reason these have to be distinct server blocks, so collapse into one and go with the more terse location block.
Signed-off-by: Luke W Faraone <luke@faraone.cc>
|
|
When we get behind on replication, we tend to stack up background processes
behind a linearizer. Bg processes are heavy (particularly with respect to
prometheus metrics) and linearizers aren't terribly efficient once the queue
gets long either.
A better approach is to maintain a queue of requests to be processed, and
nominate a single process to work its way through the queue.
Fixes: #7444
|