-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
/messages
pagination fails with "Host not in room" if backfill request goes to a server with outdated state
#12490
Comments
It seems like if I do enough small requests, I do eventually hit a point I can't paginate past even with limit=1. |
/messages
pagination fails with a limit over 91 if a remote server returns 403
At first glance, it sounds like:
|
The person paginating was in the room all the time. It isn't exactly 91 events, sometimes it is more, if you paginate in smaller batches. So this is probably some state events, that get pulled in for state res from a server, that isn't in the room anymore or so? |
I'm seeing the same thing in one of the Gitter rooms:
Because the backfill is failing:
|
/messages
pagination fails with a limit over 91 if a remote server returns 403/messages
pagination fails with "Host not in room" if backfill request goes to a server with outdated state
Presumably we should just move on to the next homeserver to try backfilling from when one returns a 4XX, rather than confusingly bubbling that request up to the client? |
Related: #12584 |
Yeah, I think this might have regressed with #7556. Though there is a bit of a balance here between trying a range of different servers, and not taking all week to reply to the client. |
Description
Users reported that their client can't scroll back past a certain point and their client shows "Host not in room". Investigating further shows that Quaternion uses a random integer as the limit, usually between 700 and 100 in the failing requests. Manually doing /messages requests works fine if limit is 91 or smaller, but fails with a limit of 92 or higher. Paginating backwards using the batch token from a 91er request works fine however. Noticeable is that in the logs the server seems to reach out to a server, that isn't in the room anymore.
Might be related to #3736
Logs:
Steps to reproduce
I have no idea, but in the affected room any /messages request with a high enough limit does reproduce it.
I would the request to either return 91 events or return 92 events as it does when splitting up the request into multiple. It clearly shouldn't fail, just because it only has 91 events to return right now or because one server doesn't answer, if it can still return some events.
Version information
If not matrix.org:
Version: 1.57.0rc1
Install method: ebuild
The text was updated successfully, but these errors were encountered: