| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| | |
matrix-org-hotfixes
|
| | |
| |
| | |
Work on https://github.com/matrix-org/matrix-doc/pull/2716
|
| | |
| |
| |
| |
| | |
We were repeatedly looking up a config option in a loop (using the
unclassed config style), which is expensive enough that it can cause
large CPU usage.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes https://github.com/matrix-org/synapse/issues/10030.
We were expecting milliseconds where we should have provided a value in seconds.
The impact of this bug isn't too bad. The code is intended to count the number of remote servers that the homeserver can see and report that as a metric. This metric is supposed to run initially 1 second after server startup, and every 60s as well. Instead, it ran 1,000 seconds after server startup, and every 60s after startup.
This fix allows for the correct metrics to be collected immediately, as well as preventing a random collection 1,000s in the future after startup.
|
| |\| |
|
| | |
| |
| | |
Hopefully fixes #10027.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This PR implements the ["Changes regarding the Public Rooms Directory"](https://github.com/Sorunome/matrix-doc/blob/soru/knock/proposals/2403-knock.md#changes-regarding-the-public-rooms-directory) section of knocking MSC2403.
Specifically, it:
* Allows rooms with `join_rule` "knock" to be returned by the query behind the public rooms directory
* Adds the field `join_rule` to each room entry returned by a public rooms directory query, so clients can know whether to attempt a join or knock on a room
Based on https://github.com/matrix-org/synapse/issues/6739. Complement tests for this change: https://github.com/matrix-org/complement/pull/72
|
| | |
| |
| |
| |
| |
| | |
This PR aims to implement the knock feature as proposed in https://github.com/matrix-org/matrix-doc/pull/2403
Signed-off-by: Sorunome mail@sorunome.de
Signed-off-by: Andrew Morgan andrewm@element.io
|
| |\ \ |
|
| | |/
| |
| | |
Hopefully fixes #10027.
|
| |\| |
|
| | |
| |
| |
| |
| | |
Related to: #6681, #5956, #10040
Signed-off-by: Dirk Klimpel dirk@klimpel.org
|
| |\| |
|
| | |
| |
| | |
Empirically, this helped my server considerably when handling gaps in Matrix HQ. The problem was that we would repeatedly call have_seen_events for the same set of (50K or so) auth_events, each of which would take many minutes to complete, even though it's only an index scan.
|
| | |
| |
| |
| |
| |
| | |
Implements MSC2414: https://github.com/matrix-org/matrix-doc/pull/2414
See #8551
Signed-off-by: Callum Brown <callum@calcuode.com>
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Make `invalidate` and `invalidate_many` do the same thing
... so that we can do either over the invalidation replication stream, and also
because they always confused me a bit.
* Kill off `invalidate_many`
* changelog
|
| | |
| |
| | |
Signed-off-by: Dirk Klimpel dirk@klimpel.org
|
| |\| |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
`keylen` seems to be a thing that is frequently incorrectly set, and we don't really need it.
The only time it was used was to figure out if we had removed a subtree in `del_multi`, which we can do better by changing `TreeCache.pop` to return a different type (`TreeCacheNode`).
Commits should be independently reviewable.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes: https://github.com/matrix-org/synapse/issues/9962
This is a fix for above problem.
I fixed it by swaping the order of insertion of new records and deletion of old ones. This ensures that we don't delete fresh database records as we do deletes before inserts.
Signed-off-by: Marek Matys <themarcq@gmail.com>
|
| | |
| |
| |
| | |
to them, instead of something in-memory (#9823)
|
| |\| |
|
| | |
| |
| |
| |
| |
| | |
- use a tuple rather than a list for the iterable that is passed into the
wrapped function, for performance
- test that we can pass an iterable and that keys are correctly deduped.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
It's not obvious that instances of SQLBaseStore each need their own
instances of random.SystemRandom(); let's just use random directly.
Introduced by 52839886d664576831462e033b88e5aba4c019e3
Signed-off-by: Dan Callahan <danc@element.io>
|
| |\| |
|
| | |
| |
| |
| |
| | |
Now that cross signing exists there is much less of a need for other people to look at devices and verify them individually. This PR adds a config option to allow you to prevent device display names from being shared with other servers.
Signed-off-by: Aaron Raimist <aaron@raim.ist>
|
| | |
| |
| |
| |
| | |
Hopefully this will help us track down where to-device messages are getting
lost/delayed.
|
| | |
| |
| |
| |
| | |
The hope here is that by moving all the schema files into synapse/storage/schema, it gets a bit easier for newcomers to navigate.
It certainly got easier for me to write a helpful README. There's more to do on that front, but I'll follow up with other PRs for that.
|
| |\| |
|
| | | |
|
| | |
| |
| |
| | |
This reverts commit 05e8c70c059f8ebb066e029bc3aa3e0cefef1019.
|
| | |
| |
| |
| | |
This reverts commit 05e8c70c059f8ebb066e029bc3aa3e0cefef1019.
|
| |\| |
|
| | | |
|
| | | |
|
| | |
| |
| | |
Fixes #9866.
|
| | |
| |
| | |
This is no longer required, since we have dropped support for Python 3.5.
|
| | | |
|
| | |
| |
| |
| |
| | |
hitting an 'Invalid Token' page #74" from synapse-dinsic (#9832)
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).
|
| |\| |
|
| | |
| |
| |
| |
| | |
Fixes: #9797.
Should help reduce CPU usage on the user directory, especially when memberships change in rooms with lots of state history.
|
| | |
| |
| |
| |
| | |
There are a couple of points in `persist_events` where we are doing a
query per event in series, which we can replace.
|
| | |
| |
| |
| |
| | |
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>`
|
| |\| |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Part of #9366
Adds in fixes for B006 and B008, both relating to mutable parameter lint errors.
Signed-off-by: Jonathan de Jong <jonathan@automatia.nl>
|
| | |\ |
|
| | | | |
|
| |\ \ \
| | |/
| |/| |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `remote_media_cache_thumbnails_media_origin_media_id_thumbna_key`
constraint is superceded by
`remote_media_repository_thumbn_media_origin_id_width_height_met` (which adds
`thumbnail_method` to the unique key).
PR #7124 made an attempt to remove the old constraint, but got the name wrong,
so it didn't work. Here we update the bg update and rerun it.
Fixes #8649.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
`room_invite_state_types` was inconvenient as a configuration setting, because
anyone that ever set it would not receive any new types that were added to the
defaults. Here, we deprecate the old setting, and replace it with a couple of
new settings under `room_prejoin_state`.
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| | |
Split off from https://github.com/matrix-org/synapse/pull/9491
Adds a storage method for getting the current presence of all local users, optionally excluding those that are offline. This will be used by the code in #9491 when a PresenceRouter module informs Synapse that a given user should have `"ALL"` user presence updates routed to them. Specifically, it is used here: https://github.com/matrix-org/synapse/blob/b588f16e391d664b11f43257eabf70663f0c6d59/synapse/handlers/presence.py#L1131-L1133
Note that there is a `get_all_presence_updates` function just above. That function is intended to walk up the table through stream IDs, and is primarily used by the presence replication stream. I could possibly make use of it in the PresenceRouter-related code, but it would be a bit of a bodge.
|
| |\| |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
We had two functions named `get_forward_extremities_for_room` and
`get_forward_extremeties_for_room` that took different paramters. We
rename one of them to avoid confusion.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Populate `internal_metadata.outlier` based on `events` table
Rather than relying on `outlier` being in the `internal_metadata` column,
populate it based on the `events.outlier` column.
* Move `outlier` out of InternalMetadata._dict
Ultimately, this will allow us to stop writing it to the database. For now, we
have to grandfather it back in so as to maintain compatibility with older
versions of Synapse.
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Federation catch up mode is very inefficient if the number of events
that the remote server has missed is small, since handling gaps can be
very expensive, c.f. #9492.
Instead of going into catch up mode whenever we see an error, we instead
do so only if we've backed off from trying the remote for more than an
hour (the assumption being that in such a case it is more than a
transient failure).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Background: When we receive incoming federation traffic, and notice that we are missing prev_events from
the incoming traffic, first we do a `/get_missing_events` request, and then if we still have missing prev_events,
we set up new backwards-extremities. To do that, we need to make a `/state_ids` request to ask the remote
server for the state at those prev_events, and then we may need to then ask the remote server for any events
in that state which we don't already have, as well as the auth events for those missing state events, so that we
can auth them.
This PR attempts to optimise the processing of that state request. The `state_ids` API returns a list of the state
events, as well as a list of all the auth events for *all* of those state events. The optimisation comes from the
observation that we are currently loading all of those auth events into memory at the start of the operation, but
we almost certainly aren't going to need *all* of the auth events. Rather, we can check that we have them, and
leave the actual load into memory for later. (Ideally the federation API would tell us which auth events we're
actually going to need, but it doesn't.)
The effect of this is to reduce the number of events that I need to load for an event in Matrix HQ from about
60000 to about 22000, which means it can stay in my in-memory cache, whereas previously the sheer number
of events meant that all 60K events had to be loaded from db for each request, due to the amount of cache
churn. (NB I've already tripled the size of the cache from its default of 10K).
Unfortunately I've ended up basically C&Ping `_get_state_for_room` and `_get_events_from_store_or_dest` into
a new method, because `_get_state_for_room` is also called during backfill, which expects the auth events to be
returned, so the same tricks don't work. That said, I don't really know why that codepath is completely different
(ultimately we're doing the same thing in setting up a new backwards extremity) so I've left a TODO suggesting
that we clean it up.
|
| | |
| |
| |
| |
| |
| | |
... because namedtuples suck
Fix up a couple of other annotations to keep mypy happy.
|
| | |
| |
| |
| | |
This uses a simplified version of get_chain_cover_difference to calculate
auth chain of events.
|
| | | |
|
| | |
| |
| |
| |
| | |
This is a companion change to apply the fix in #9498 /
922788c6043138165c025c78effeda87de842bab to previously
purged rooms.
|
| |\| |
|
| | |
| |
| |
| | |
Turns out matrix.org has an event that has duplicate auth events (which really isn't supposed to happen, but here we are). This caused the background update to fail due to `UniqueViolation`.
|
| | | |
|
| | | |
|
| |\| |
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| | |
It landed in schema version 58 after 59 had been created, causing some
servers to not run it. The main effect of was that not all rooms had
their chain cover calculated correctly. After the BG updates complete
the chain covers will get fixed when a new state event in the affected
rooms is received.
|
| | |
| |
| |
| | |
Fixes #9504
|
| |\| |
|
| | | |
|
| | | |
|
| | |
| |
| | |
The idea here is to stop people forgetting to call `check_consistency`. Folks can still just pass in `None` to the new args in `build_sequence_generator`, but hopefully they won't.
|
| | |
| |
| | |
And ensure the consistency of `event_auth_chain_id`.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
This PR remove the cache for the `get_shared_rooms_for_users` storage method (the db method driving the experimental "what rooms do I share with this user?" feature: [MSC2666](https://github.com/matrix-org/matrix-doc/pull/2666)). Currently subsequent requests to the endpoint will return the same result, even if your shared rooms with that user have changed.
The cache was added in https://github.com/matrix-org/synapse/pull/7785, but we forgot to ensure it was invalidated appropriately.
Upon attempting to invalidate it, I found that the cache had to be entirely invalidated whenever a user (remote or local) joined or left a room. This didn't make for a very useful cache, especially for a function that may or may not be called very often. Thus, I've opted to remove it instead of invalidating it.
|
| |\| |
|
| | |\ |
|
| | | | |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
results (#9383)
This PR adds a homeserver config option, `user_directory.prefer_local_users`, that when enabled will show local users higher in user directory search results than remote users. This option is off by default.
Note that turning this on doesn't necessarily mean that remote users will always be put below local users, but they should be assuming all other ranking factors (search query match, profile information present etc) are identical.
This is useful for, say, University networks that are openly federating, but want to prioritise local students and staff in the user directory over other random users.
|
| |\| |
|
| | |
| |
| |
| |
| |
| | |
(#9428)
As the comment says, this guard was there for when the
initial user directory update has yet to happen.
|
| |\|
| |
| |
| | |
Merge the cookie fix to hotfixes
|
| | | |
|
| |\| |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
- Update black version to the latest
- Run black auto formatting over the codebase
- Run autoformatting according to [`docs/code_style.md
`](https://github.com/matrix-org/synapse/blob/80d6dc9783aa80886a133756028984dbf8920168/docs/code_style.md)
- Update `code_style.md` docs around installing black to use the correct version
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
(#9003)
Remove conflicting sqlite tables that throw sqlite3.OperationalError: object name reserved for internal use: event_search_content when running the twisted unit tests.
Fix #8996
|
| |\| |
|
| | |\ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes #8966.
* Factor out build_synapse_client_resource_tree
Start a function which will mount resources common to all workers.
* Move sso init into build_synapse_client_resource_tree
... so that we don't have to do it for each worker
* Fix SSO-login-via-a-worker
Expose the SSO login endpoints on workers, like the documentation says.
* Update workers config for new endpoints
Add documentation for endpoints recently added (#8942, #9017, #9262)
* remove submit_token from workers endpoints list
this *doesn't* work on workers (yet).
* changelog
* Add a comment about the odd path for SAML2Resource
|
| | | |\
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Synapse 1.26.0rc2 (2021-01-25)
==============================
Bugfixes
--------
- Fix receipts and account data not being sent down sync. Introduced in v1.26.0rc1. ([\#9193](https://github.com/matrix-org/synapse/issues/9193), [\#9195](https://github.com/matrix-org/synapse/issues/9195))
- Fix chain cover update to handle events with duplicate auth events. Introduced in v1.26.0rc1. ([\#9210](https://github.com/matrix-org/synapse/issues/9210))
Internal Changes
----------------
- Add an `oidc-` prefix to any `idp_id`s which are given in the `oidc_providers` configuration. ([\#9189](https://github.com/matrix-org/synapse/issues/9189))
- Bump minimum `psycopg2` version to v2.8. ([\#9204](https://github.com/matrix-org/synapse/issues/9204))
|
| | | | |
| | | |
| | | | |
Signed-off-by: Jan Christian Grünhage <jan.christian@gruenhage.xyz>
|
| | | | |
| | | |
| | | | |
This finishes adding type hints to the `synapse.handlers` module.
|
| | | | |
| | | |
| | | |
| | | | |
With this change all handlers except the e2e_* ones have
type hints enabled.
|
| |\| | | |
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: Jason Robinson <jasonr@matrix.org>
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
# Conflicts:
# synapse/rest/admin/__init__.py
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This expands the current shadow-banning feature to be usable via
the admin API and adds documentation for it.
A shadow-banned users receives successful responses to their
client-server API requests, but the events are not propagated into rooms.
Shadow-banning a user should be used as a tool of last resort and may lead
to confusing or broken behaviour for the client.
|
| | | | | |
| | | | |
| | | | | |
Co-authored-by: Erik Johnston <erik@matrix.org>
|
| | |\| | | |
|
| | | | | | |
|
| | | |\ \ \
| | | | |/
| | | |/| |
|
| | | |\ \ \ |
|
| | | | |_|/
| | |/| |
| | | | |
| | | | |
| | | | | |
* Use execute_batch in more places
* Newsfile
|
| | | | | |
| | | | |
| | | | | |
`execute_batch` does fewer round trips in postgres than `executemany`, but does not give a correct `txn.rowcount` result after.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Also add a warning on the admin API documentation.
Signed-off-by: Jason Robinson <jasonr@matrix.org>
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: Jason Robinson <jasonr@matrix.org>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As per feedback.
Signed-off-by: Jason Robinson <jasonr@matrix.org>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* docs updates
* prettify SQL
* add missing copyright
* cursor_to_dict
* update touched files copyright years
Signed-off-by: Jason Robinson <jasonr@matrix.org>
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: Jason Robinson <jasonr@matrix.org>
|
| | |\ \ \ \ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Also run linter.
Signed-off-by: Jason Robinson <jasonr@matrix.org>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Signed-off-by: Jason Robinson <jasonr@matrix.org>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
GET /_synapse/admin/v1/rooms/<identifier>/forward_extremities now gets forward extremities for a room, returning count and the list of extremities.
Signed-off-by: Jason Robinson <jasonr@matrix.org>
|
| |\ \ \ \ \ \
| | |_|_|_|/
| |/| | | | |
|
| | | |_|_|/
| |/| | | |
|
| | | |_|/
| |/| |
| | | |
| | | |
| | | | |
Introduced in #9104
This wasn't picked up by the tests as this is all fine the first time you run Synapse (after upgrading), but then when you restart the wrong value is pulled from `stream_positions`.
|
| | | | | |
|
| |\| | | |
|
| | | | | |
|
| |\| | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We do this by allowing a single iteration to process multiple rooms at a
time, as there are often a lot of really tiny rooms, which can massively
slow things down.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
I don't think there's any need to use canonicaljson here.
Fixes: #4475.
|
| | | | | |
|
| |\| | | |
|
| | | | | |
|
| |\| | | |
|
| | | | |
| | | |
| | | |
| | | | |
(#9115)
|
| | | | |
| | | |
| | | |
| | | | |
t was doing a sequential scan on `destination_rooms`, which took
minutes.
|
| |\| | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | | |
This only applies if the user's data is to be erased.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
These tables are unused, and can be dropped now the schema version has been bumped.
|
| | | | |
| | | |
| | | | |
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
|
| | | |/
| |/|
| | |
| | |
| | | |
* Dropped last_used column from access_tokens
Signed-off-by: Jerin J Titus <72017981+jerinjtitus@users.noreply.github.com>
|
| | |/
| |
| |
| |
| | |
You can't continue using a transaction once an exception has been
raised, so catching and dropping the error here is pointless and just
causes more errors.
|
| |\| |
|
| | | |
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| | |
This allows for efficiently finding which users ignore a particular
user.
Co-authored-by: Erik Johnston <erik@matrix.org>
|
| |\| |
|
| | | |
|
| | | |
|
| | |
| |
| | |
This table has been unused since Synapse v1.17.0.
|
| | | |
|
| | |
| |
| |
| |
| | |
* Use the simple dictionary in fts for the user directory
* Clarify naming
|
| | | |
|
| | |
| |
| | |
This improves type hinting and should use less memory.
|
| | | |
|
| |\| |
|
| | |
| |
| |
| | |
Removes faulty assertions and fixes the logic to ensure the max
stream token is always set.
|
| |\| |
|
| | | |
|
| | |
| |
| |
| |
| | |
This is so that we can choose which algorithm to use based on the room ID.
|
| | |
| |
| |
| |
| |
| |
| | |
During user-interactive auth, do not offer password auth to users with no
password, nor SSO auth to users with no SSO.
Fixes #7559.
|
| |\|
| |
| |
| | |
matrix-org-hotfixes
|
| | |
| |
| |
| |
| |
| |
| | |
It's important that we make sure our background updates happen in a defined
order, to avoid disasters like #6923.
Add an ordering to all of the background updates that have landed since #7190.
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is another PR that grew out of #6739.
The existing code for checking whether a user is currently invited to a room when they want to leave the room looks like the following:
https://github.com/matrix-org/synapse/blob/f737368a26bb9eea401fcc3a5bdd7e0b59e91f09/synapse/handlers/room_member.py#L518-L540
It calls `get_invite_for_local_user_in_room`, which will actually query *all* rooms the user has been invited to, before iterating over them and matching via the room ID. It will then return a tuple of a lot of information which we pull the event ID out of.
I need to do a similar check for knocking, but this code wasn't very efficient. I then tried to write a different implementation using `StateHandler.get_current_state` but this actually didn't work as we haven't *joined* the room yet - we've only been invited to it. That means that only certain tables in Synapse have our desired `invite` membership state. One of those tables is `local_current_membership`.
So I wrote a store method that just queries that table instead
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
no stream_id is stored. (#8744)
* Make this line debug (it's noisy)
* Don't include from_key for presence if we are at 0
* Limit read receipts for all rooms to 100
* changelog.d/8744.bugfix
* Allow from_key to be None
* Update 8744.bugfix
* The from_key is superflous
* Update comment
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
There's a handy function called maybe_store_room_on_invite which allows us to create an entry in the rooms table for a room and its version for which we aren't joined to yet, but we can reference when ingesting events about.
This is currently used for invites where we receive some stripped state about the room and pass it down via /sync to the client, without us being in the room yet.
There is a similar requirement for knocking, where we will eventually do the same thing, and need an entry in the rooms table as well. Thus, reusing this function works, however its name needs to be generalised a bit.
Separated out from #6739.
|
| |\| |
|
| | |
| |
| |
| |
| | |
This should hopefully speed up `get_auth_chain_difference` a bit in the case of repeated state res on the same rooms.
`get_auth_chain_difference` does a breadth first walk of the auth graphs by repeatedly looking up events' auth events. Different state resolutions on the same room will end up doing a lot of the same event to auth events lookups, so by caching them we should speed things up in cases of repeated state resolutions on the same room.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Add `GET /_synapse/admin/v1/statistics/users/media` to get statisics about local media usage by users.
Related to #6094
It is the first API for statistics.
Goal is to avoid/reduce usage of sql queries like [Wiki analyzing Synapse](https://github.com/matrix-org/synapse/wiki/SQL-for-analyzing-Synapse-PostgreSQL-database-stats)
Signed-off-by: Dirk Klimpel dirk@klimpel.org
|
| | |
| |
| | |
We do a `SELECT MAX(stream_id) FROM e2e_cross_signing_keys` on startup.
|
| |\| |
|
| | | |
|
| |\| |
|
| | |
| |
| | |
Fixes #6755
|
| | |
| |
| | |
Missed in #8671.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
another user. (#8616)
We do it this way round so that only the "owner" can delete the access token (i.e. `/logout/all` by the "owner" also deletes that token, but `/logout/all` by the "target user" doesn't).
A future PR will add an API for creating such a token.
When the target user and authenticated entity are different the `Processed request` log line will be logged with a: `{@admin:server as @bob:server} ...`. I'm not convinced by that format (especially since it adds spaces in there, making it harder to use `cut -d ' '` to chop off the start of log lines). Suggestions welcome.
|
| | |\
| | |
| | | |
Fix serialisation errors when using third-party event rules.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Not being able to serialise `frozendicts` is fragile, and it's annoying to have
to think about which serialiser you want. There's no real downside to
supporting frozendicts, so let's just have one json encoder.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
I was trying to make it so that we didn't have to start a background task when handling RDATA, but that is a bigger job (due to all the code in `generic_worker`). However I still think not pulling the event from the DB may help reduce some DB usage due to replication, even if most workers will simply go and pull that event from the DB later anyway.
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a requirement for [knocking](https://github.com/matrix-org/synapse/pull/6739), and is abstracting some code that was originally used by the invite flow. I'm separating it out into this PR as it's a fairly contained change.
For a bit of context: when you invite a user to a room, you send them [stripped state events](https://matrix.org/docs/spec/server_server/unstable#put-matrix-federation-v2-invite-roomid-eventid) as part of `invite_room_state`. This is so that their client can display useful information such as the room name and avatar. The same requirement applies to knocking, as it would be nice for clients to be able to display a list of rooms you've knocked on - room name and avatar included.
The reason we're sending membership events down as well is in the case that you are invited to a room that does not have an avatar or name set. In that case, the client should use the displayname/avatar of the inviter. That information is located in the inviter's membership event.
This is optional as knocks don't really have any user in the room to link up to. When you knock on a room, your knock is sent by you and inserted into the room. It wouldn't *really* make sense to show the avatar of a random user - plus it'd be a data leak. So I've opted not to send membership events to the client here. The UX on the client for when you knock on a room without a name/avatar is a separate problem.
In essence this is just moving some inline code to a reusable store method.
|
| |\| | |
|
| | | |
| | |
| | | |
Add admin API `GET /_synapse/admin/v1/users/<user_id>/media` to get information of users' uploaded files.
|
| | | |
| | |
| | | |
This also fixes a bug by fixing handling of an account which doesn't expire.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Split admin API for reported events in detail und list view.
API was introduced with #8217 in synapse v.1.21.0.
It makes the list (`GET /_synapse/admin/v1/event_reports`) less complex and provides a better overview.
The details can be queried with: `GET /_synapse/admin/v1/event_reports/<report_id>`.
It is similar to room and users API.
It is a kind of regression in `GET /_synapse/admin/v1/event_reports`. `event_json` was removed. But the api was introduced one version before and it is an admin API (not under spec).
Signed-off-by: Dirk Klimpel dirk@klimpel.org
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Related to: #6459, #3479
Add `DELETE /_synapse/admin/v1/media/<server_name>/<media_id>` to delete
a single file from server.
|
| | |\| |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | |/
| |/| |
|
| | | | |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Fix user_daily_visits to not have duplicate rows for UA.
Fixes #8641.
* Newsfile
* Fix typo.
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
|
| |\| |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
* Move schema file
* Add a .
* Add matching changelog entry
* Fix sqlite
|
| | |
| |
| | |
Signed-off-by: Vasilis Gerakaris <vasilis.gerakaris@navarino.gr>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Add `DeferredCache.get_immediate` method
A bunch of things that are currently calling `DeferredCache.get` are only
really interested in the result if it's completed. We can optimise and simplify
this case.
* Remove unused 'default' parameter to DeferredCache.get()
* another get_immediate instance
|
| | |
| |
| | |
Most of these uses don't need a full-blown DeferredCache; LruCache is lighter and more appropriate.
|
| | | |
|
| |\| |
|
| | |
| |
| | |
Optionally sends typing, presence, and read receipt information to appservices.
|
| | |\
| | |
| | | |
Rename Cache to DeferredCache, and related changes
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | | |
Include user agent in user daily visits table.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Autocommit means that we don't wrap the functions in transactions, and instead get executed directly. Introduced in #8456. This will help:
1. reduce the number of `could not serialize access due to concurrent delete` errors that we see (though there are a few functions that often cause serialization errors that we don't fix here);
2. improve the DB performance, as it no longer needs to deal with the overhead of `REPEATABLE READ` isolation levels; and
3. improve wall clock speed of these functions, as we no longer need to send `BEGIN` and `COMMIT` to the DB.
Some notes about the differences between autocommit mode and our default `REPEATABLE READ` transactions:
1. Currently `autocommit` only applies when using PostgreSQL, and is ignored when using SQLite (due to silliness with [Twisted DB classes](https://twistedmatrix.com/trac/ticket/9998)).
2. Autocommit functions may get retried on error, which means they can get applied *twice* (or more) to the DB (since they are not in a transaction the previous call would not get rolled back). This means that the functions need to be idempotent (or otherwise not care about being called multiple times). Read queries, simple deletes, and updates/upserts that replace rows (rather than generating new values from existing rows) are all idempotent.
3. Autocommit functions no longer get executed in [`REPEATABLE READ`](https://www.postgresql.org/docs/current/transaction-iso.html) isolation level, and so data can change queries, which is fine for single statement queries.
|
| |\| | |
|
| | |/
| |
| |
| |
| | |
* Make sure a retention policy is a state event
* Changelog
|
| |\| |
|
| | | |
|
| | |
| |
| |
| |
| | |
(#8476)
Should fix #3365.
|
| | |
| |
| |
| |
| | |
When pulling events out of the DB to send over replication we were not
filtering by instance name, and so we were sending events for other
instances.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently when using multiple event persisters we (in the worst case) don't tell clients about events until all event persisters have persisted new events after the original event. This is a suboptimal, especially if one of the event persisters goes down.
To handle this, we encode the position of each event persister in the room tokens so that we can send events to clients immediately. To reduce the size of the token we do two things:
1. We create a unique immutable persistent mapping between instance names and a generated small integer ID, which we can encode in the tokens instead of the instance name; and
2. We encode the "persisted upto position" of the room token and then only explicitly include instances that have positions strictly greater than that.
The new tokens look something like: `m3478~1.3488~2.3489`, where the first number is the min position, and the subsequent `-` separated pairs are the instance ID to positions map. (We use `.` and `~` as separators as they're URL safe and not already used by `StreamToken`).
|
| | | |
|
| | |
| |
| |
| | |
This allows a user to store an offline device on the server and
then restore it at a subsequent login.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
There's no need for it to be in the dict as well as the events table. Instead,
we store it in a separate attribute in the EventInternalMetadata object, and
populate that on load.
This means that we can rely on it being correctly populated for any event which
has been persited to the database.
|
| | |
| |
| |
| | |
This fixes a bug where `m.ignored_user_list` was assumed to be a dict,
leading to odd behavior for users who set it to something else.
|
| | |
| |
| |
| |
| | |
This is so we can tell what is going on when things are taking a while to start up.
The main change here is to ensure that transactions that are created during startup get correctly logged like normal transactions.
|
| | | |
|
| | | |
|
| |\| |
|
| | | |
|
| | |
| |
| |
| | |
I think this came from a bad merge
|
| |\| |
|
| | |
| |
| | |
The idea is that in future tokens will encode a mapping of instance to position. However, we don't want to include the full instance name in the string representation, so instead we'll have a mapping between instance name and an immutable integer ID in the DB that we can use instead. We'll then do the lookup when we serialize/deserialize the token (we could alternatively pass around an `Instance` type that includes both the name and ID, but that turns out to be a lot more invasive).
|
| | |
| |
| |
| |
| | |
Hopefully, N(extremities) * N(state_events) is a more realistic approximation
to "how big a problem is this room?".
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was a bit unweildy for what I wanted: in particular, I wanted to assign
each measurement straight into a bucket, rather than storing an intermediate
Counter which didn't do any bucketing at all.
I've replaced it with something that is hopefully a bit easier to use.
(I'm not entirely sure what the difference between a HistogramMetricFamily and
a GaugeHistogramMetricFamily is, but given our counters can go down as well as
up the latter *sounds* more accurate?)
|
