In reply to @ben:radey.org
Dang. Although I did expect a lot of hallucinations, there's not a lot of manhole documentation that I could even find for myself, let alone for ChatGPT to train on

MSC2213: Rejoinability of private/invite-only rooms by @turt2live

In reply to @blackmad:matrix.org
I'm still wondering - if I want to fetch one specific event for a room, say PowerLevels, is it better to call get_current_state_ids with a StateFilter for that one specific event - which means the query won't be cached and I'll be relying on postgres performance, or call get_current_state_ids with no filter, get the full list of cached ids and just pull out the PowerLevels event. It seems like the latter would be faster, but given that, I don't understand why that's not how it's implemented in code?

Wouldn't it still be cached, but just only for that room and state event type/key?

I imagine we just didn't think to implement a get_current_state_ids with a None state filter with that optimisation, rather than explicitly not implementing it in that way. Indeed, feel free to suggest that if you think it'll make a theoretical difference!

It's a bit tricky to prove that it would be faster in all cases though. For a room with 100,000 users, pulling all of that member state would be far more work than just a single power levels event, in case the result isn't cached.

could also make it such that we check if the full state in the cache and use that if so?

That sounds worthwhile!

{
  "auth": {
    "session": "<session obtained with first /account/deactivate request>"
  }
}

{
  "session": "<session>",
  "flows": [],
  "params": {},
  "completed": []
}

Till I would bump:

This release candidate contains the security fixes from v1.120.2.

up until the Synapse 1.121.0 (2024-12-11) header, and then delete "New changes listed below.".

Otherwise LGTM!