Avoid backfill when we already have messages to return

[MadLittleMods]

Avoid backfill when we already have messages to return.

We now only block the client to backfill when we see a large gap in the events (more than 2 events missing in a row according to depth), more than 3 single-event holes, or not enough messages to fill the response. Otherwise, we return the messages directly to the client and backfill in the background for eventual consistency sake.

Fix #15696

Figure out if this change would skip backfill in a real-world scenario

For a real-world example with the trace linked from the issue (from viewing the Matrix Public Archive), it makes the following /messages request. If we run the JS snippet over the response, we can see that there are no gaps in response and we didn't really need to backfill at all. Which means this PR is a good change and would allow us not to block the client waiting for backfill which equates to 14s savings out of that 16s request!

GET https://matrix-client.matrix.org/_matrix/client/r0/rooms/!OGEhHVWSdvArJzumhm%3Amatrix.org/messages?dir=b&from=t535491-3610842373_0_0_0_0_0_0_0_0_0&limit=101&filter=%7B%22lazy_load_members%22%3Atrue%2C%22event_format%22%3A%22federation%22%7D

(() => {
    const rawEventDepthList = messagesResponse1.chunk.map((event) => {
        return event.depth;
    });
    // Unique sorted event depths
    const sortedEventDepths = Array.from(new Set(rawEventDepthList.sort()).values());

    let foundBigGap = false;
    let numberOfGaps = 0;
    let previousEventDepth = sortedEventDepths[0];
    for (const eventDepth of sortedEventDepths) {
        const depthGap = eventDepth - previousEventDepth;
        console.log('depthGap', depthGap);
        if (depthGap > 1) {
            numberOfGaps += 1;
        }

        if (depthGap > 2) {
            foundBigGap = true;
        }

        previousEventDepth = eventDepth;
    }

    console.log('numberOfGaps', numberOfGaps);
    console.log('foundBigGap', foundBigGap);
})();

Dev notes

Other PR where we did some backfill/processing in the background, #15585

MSC3871: Gappy timelines

Pull Request Checklist

• Pull request is based on the develop branch
• Pull request includes a changelog file. The entry should:
  • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
  • Use markdown where necessary, mostly for code blocks.
  • End with either a period (.) or an exclamation mark (!).
  • Start with a capital letter.
  • Feel free to credit yourself, by adding a sentence "Contributed by @github_username." or "Contributed by [Your Name]." to the end of the entry.
• Pull request includes a sign off
• Code style is correct
  (run the linters)

[MadLittleMods]

This logic is just pulled out from the existing condition to de-nest it further up here and have it ready when we initially fetch.

[MadLittleMods]

In the worst case now when we do need to backfill, it does mean that we call paginate_room_events() twice but I think the savings in the happy-path is well worth it.

Plus a slow backfill that is 10+ seconds for the federation request and processing doesn't hurt from an extra 250ms paginate_room_events() call again (it's not the slowest piece about this whole process to worry about here anyway).

[erikjohnston]

Since the list is sorted won't this always be positive even if there are negative depths?

[MadLittleMods]

Yes

ex. -5 - -6 = 1

🤷 Perhaps this gets across that we care about the absolute distance, not the difference in any case.

[MadLittleMods]

Thanks for the review @erikjohnston 🐨