Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

/state_ids returns huge amounts of pointless data #2397

Closed
richvdh opened this issue Jan 2, 2020 · 1 comment
Closed

/state_ids returns huge amounts of pointless data #2397

richvdh opened this issue Jan 2, 2020 · 1 comment
Labels
s2s Server-to-Server API (federation) wart A point where the protocol is inconsistent or inelegant

Comments

@richvdh
Copy link
Member

richvdh commented Jan 2, 2020

Currently, /state_ids is specced to return 'The full set of authorization events that make up the state of the room, and their authorization events, recursively.'

Thankfully it appears to mean the ids of those events rather than the events themselves, but still, this can be a huge amount of data (causing synapse to OOM: matrix-org/synapse#6597), and I don't understand why any of it is helpful. The auth events of a given event are embedded in the (signed and hashed part of) the event itself, so if we have the event itself, we know its auth events. The auth event ids are no use without the event itself, so... what is the point of this?

Unfortunately it's not entirely easy to fix this because, at least up until Synapse 1.7.0, Synapse actually relies on the auth events being present to make backfill work correctly; I guess we'll need a /v2/state_ids.

@turt2live turt2live added s2s Server-to-Server API (federation) wart A point where the protocol is inconsistent or inelegant labels Jan 2, 2020
@richvdh
Copy link
Member Author

richvdh commented Jul 19, 2020

On reflection, this seems to be correct behaviour.

@richvdh richvdh closed this as completed Jul 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
s2s Server-to-Server API (federation) wart A point where the protocol is inconsistent or inelegant
Projects
None yet
Development

No branches or pull requests

2 participants