Spec is unclear whether send_join state response should be deduped #2464
Assignees
Labels
clarification
An area where the spec could do with being more explicit
s2s
Server-to-Server API (federation)
Comments
|
for the record: it should be the resolved state at (before? after?) the join event. The joining server lacks the information to do a state res. |
richvdh
added
clarification
turt2live
added a commit
that referenced
this issue
May 25, 2020
Fixes #2467 Fixes #2464 This is based on looking at Synapse, not actually testing it. Within the send_join handling functions, an "event context" is acquired [here](https://github.com/matrix-org/synapse/blob/d14c4d6b6d02e8c55a6647ce0f0b3b44356d6173/synapse/handlers/federation.py#L1472) which then later uses the previous state (populated [here](https://github.com/matrix-org/synapse/blob/d14c4d6b6d02e8c55a6647ce0f0b3b44356d6173/synapse/state/__init__.py#L286-L289) in the event context) [here](https://github.com/matrix-org/synapse/blob/d14c4d6b6d02e8c55a6647ce0f0b3b44356d6173/synapse/handlers/federation.py#L1494-L1501) to return a response. Within the event context, the previous state IDs are populated [here](https://github.com/matrix-org/synapse/blob/d14c4d6b6d02e8c55a6647ce0f0b3b44356d6173/synapse/state/__init__.py#L351).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Federation API spec is unclear about whether a
statekey in the response to aPUT /_matrix/federation/v1/send_join/{roomId}/{eventId}can legally contain duplicate state-key tuples (for state resolution by the receiver), or whether it should be strictly resolved state with no duplicate state-key tuples.The text was updated successfully, but these errors were encountered: