Previously we would "start" the roomserver API, which isn't the best
idea, given it also starts processing Jetstream events. We now use a
`dummyQuerier` to implement the needed interface for "converting"
userID/senderIDs. As per the comment, this **DOES NOT** do any magic for
pseudoID rooms.
Previously we would update `m.direct` once we found the old room ID. If
the roomID is found somewhere in the middle, we would never add the rest
of the users, resulting in only partially upgraded `m.direct` and chats
loosing their 1:1 flag.
When we're adding state to the database, we check which eventNIDs are
already in a block, if we already have that eventNID, we remove it from
the list. In its current form we would skip over eventNIDs in the case
we already found a match (we're decrementing `i` twice)
My theory is, that when we later get the state blocks, we are receiving
"too many" eventNIDs (well, yea, we stored too many), which may or may
not can result in state resets when comparing different state snapshots.
(e.g. when adding state we stored a eventNID by accident because we
skipped it, later we add more state and are not adding it because we
don't skip it)
This set of changes introduces a few (compatible) changes to the Helm
chart:
- Allow PVC class to be set on each PVC, not only one-for-all.
- Allow Prometheus servicemonitor and rules labels to be empty.
- Have the option to generate the ingress (incl. TLS config) based on
dendrite_config.
* [x] I have added Go unit tests or [Complement integration
tests](https://github.com/matrix-org/complement) for this PR _or_ I have
justified why this PR doesn't need tests
* [x] Pull request includes a [sign off below using a legally
identifiable
name](https://matrix-org.github.io/dendrite/development/contributing#sign-off)
_or_ I have already signed off privately
Signed-off-by: Omar Pakker <Omar007@users.noreply.github.com>
---------
Signed-off-by: Omar Pakker <Omar007@users.noreply.github.com>
Co-authored-by: Till <2353100+S7evinK@users.noreply.github.com>
This should fix two issues with backfilling:
1. right after creating and joining a room over federation, we are doing
a `/backfill` request, which would return redacted events, because the
`authEvents` are empty. Even though the spec states that, in the absence
of a history visibility event, it should be handled as `shared`.
2. `gomatrixserverlib: unsupported room version ''` - because, well, we
were never setting the `roomInfo` field..
I thought I would rearrange these pages since the configuration step
requires that a signing key has been generated.
Co-authored-by: kegsay <kegan@matrix.org>
Return multimedia with a disposition type of attachment instead of
inline. NVT#1548992
Signed-off-by: Josh Qou [jqou@icloud.com](mailto:jqou@icloud.com)
Co-authored-by: Jon <haddock.05.roast@icloud.com>
