Open richvdh opened 3 years ago
this room is continuing to cause severe problems on my server. I'm going to leave it to try to make federation work again.
(Doing /join
on that room, it looks to be the "IRC Matrix Bridges" room, for anyone's reference, #irc:matrix.org
)
The main problem here is that _check_event_auth
, and its helper _update_auth_events_and_context_for_auth
, make incorrect assumptions about whether the auth events being passed in in claimed_auth_event_map
have themselves been authed. Unfortunately it's not quite as simple as just checking that they have been authed, because the whole reason we have claimed_auth_event_map
(rather than just pulling the events out of the db) is that they haven't been persisted, either.
Really, we need to get rid of the whole premise of claimed_auth_event_map
- we should not be persisting events before their auth_events are persisted. Unfortunately, if we just remove it, auth_events
does something completely different wherein it tries to work out what the auth events should be based on the current state of the room.
The two methods are also very confused about whether the auth events they are working with are those according to the auth_events
of the event being persisted, or what we think the auth events should be given the state of the room at that point (which obviously only makes sense for non-outliers, not that that stops us trying to do it anyway).
backfill
and get_missing_events
(#10615, #10624, #10640, #10645)_check_event_auth
is given a claimed_auth_event_map
iff event is an outlier - which will then mean we can split it and _update_auth_events_and_context_for_auth
in half. (#10926)claimed_auth_event_map
, the events in question have been persisted first. (#10771, #10896)event_auth.check
checks for rejected events. (#10956)_persist_auth_tree
auths auth_events correctly. _persist_auth_tree
is only used when processing the results of a send_join
(ie, when joining a new room over federation). It seems to fetch missing auth events over federation, but never actually persists them? (#11012)So I think we now have PRs that should stop this happening again in the future. The next question is whether we can do anything about existing brokenness in peoples' databases.
The next question is whether we can do anything about existing brokenness in peoples' databases.
I actually had a heated discussion about this in #matrix-spec yesterday, the consensus (and logical decision) is to - when re-validating - throw away the entire history of a room from that point on.
Here is a link to the discussion, but the talk about this requirement and me wrestling with it and trying to find an alternative is a bit further up and down from that point.
Thank you for clarifying that the issue has been fixed, though.
@richvdh #11012 described itself as "the final piece of the jigsaw for #9595"
With that merged, can we can close this issue?
I guess so. The problem is that we're still going to see this on an ongoing basis until we clear out existing problematic data.
Is this related to a batch of rooms I can't join that I saved the join links to that when pressed all give "Auth events could not be found"?
Can someone help me clear the database entries in my postgres db so I can join these rooms?
I can join other rooms but once I've "poisoned" a room with a join link then I can't enter that room even if I manually find it through the room browser.
Here are the join links (beware they will probably break the rooms for you too)
https://matrix.to/#/!EoRhMvNpnWxCMTMPeP:libera.chat?via=geese.party&via=libera.chat&via=matrix.org
https://matrix.to/#/!YLTeaulxSDauOOxBoR:matrix.org?via=geese.party&via=gitter.im&via=matrix.org
https://matrix.to/#/!GryYovOTNVgikENmcX:libera.chat?via=geese.party&via=libera.chat&via=matrix.org
I guess so. The problem is that we're still going to see this on an ongoing basis until we clear out existing problematic data.
Do we have a way to fix the database ? I have several channel with this issue. @richvdh
UPDATE: I did upgrade the room. People can join the new room. However the previous room still is not accesible from Click here to show older message
I guess so. The problem is that we're still going to see this on an ongoing basis until we clear out existing problematic data.
Do we have a way to fix the database ? I have several channel with this issue. @richvdh
UPDATE: I did upgrade the room. People can join the new room. However the previous room still is not accesible from
Click here to show older message
@parisni What do you mean “upgrade room”? could you tell how to do that? i have same issue and i just want can join new room.
This will make the current room read-only, and create a new room see rfc.
Simply type this as a message (you will be asked to invite every participant) :
/upgraderoom 7
Run an api request :
curl -H 'Authorization: Bearer <token-access>' -H "Content-Type: application/json" -X POST https://matrix.interhop.org/_matrix/client/r0/rooms/<room-id-url-encoded>/upgrade -d '{"new_version": "6"}'
in my database,
$h+BUjV0LuuSRmFh5ZFeSVZkP+oo6v7bhyJ+1wYjpLb4
(a regular membership event) uses$NncVOvrPzkKl0u1Q8FIJ7Pz1kZH1iF2lwWj6pZ6+Kkg
(a membership event which was rejected due to missing auth events) as an auth event. This seems wrong:$h+BUjV0LuuSRmFh5ZFeSVZkP+oo6v7bhyJ+1wYjpLb4
should have been rejected too.Logs from the arrival of that event: