Change Details

I haven't actually seen this in the wild, but I think since ContributionsQuery::getResult does filtering after the actual query (and doesn't re-query) it could have a similar issue to {T108279}. Since the Flow results are mixed in with non-Flow (then sorted), I think it would be more likely to happen if you had a high proportion of Flow edits. Best solution is probably to have ContributionsQuery re-query until either the filtered set is equal to the limit, or there's nothing left in the DB (which is how the pagination detection is supposed to work). Alternative approach: Move filtering to ContributionsLineEnding; this is slightly evil since ContributionsLineEnding is only supposed to format, and the abort code is a fallback (complete with HTML comment in output). (Side note, RecentChanges, the last type changed by {417f2b4c58829c2eaa025c4241367bd33fe8f8f9} does not seem negatively affected since it only calls excludeFromRecentChanges in loadMetadataBatch (which is just preloading) and getResult (which is called at the last moment so shouldn't affect pagination), and I think RC pagination works differently so this type of issue doesn't apply anyway.

I haven't actually seen this in the wild, but I think since ContributionsQuery::getResult does filtering after the actual query (and doesn't re-query) it could have a similar issue to {T108279}. Since the Flow results are mixed in with non-Flow (then sorted), I think it would be more likely to happen if you had a high proportion of Flow edits. Best solution is probably to have ContributionsQuery re-query until either the filtered set is equal to the limit, or there's nothing left in the DB (which is how the pagination detection is supposed to work). Alternative approach: Move filtering to ContributionsLineEnding; this is slightly evil since ContributionsLineEnding is only supposed to format, and the abort code is a fallback (complete with HTML comment in output). (Side note, RecentChanges, the last type changed by {417f2b4c58829c2eaa025c4241367bd33fe8f8f9} does not seem negatively affected since it only calls excludeFromRecentChanges in loadMetadataBatch (which is just preloading) and getResult (which is called at the last moment so shouldn't affect pagination), and I think RC pagination works differently so this type of issue doesn't apply anyway. But see {T109549}.

I haven't actually seen this in the wild, but I think since ContributionsQuery::getResult does filtering after the actual query (and doesn't re-query) it could have a similar issue to {T108279}. Since the Flow results are mixed in with non-Flow (then sorted), I think it would be more likely to happen if you had a high proportion of Flow edits. Best solution is probably to have ContributionsQuery re-query until either the filtered set is equal to the limit, or there's nothing left in the DB (which is how the pagination detection is supposed to work). Alternative approach: Move filtering to ContributionsLineEnding; this is slightly evil since ContributionsLineEnding is only supposed to format, and the abort code is a fallback (complete with HTML comment in output). (Side note, RecentChanges, the last type changed by {417f2b4c58829c2eaa025c4241367bd33fe8f8f9} does not seem negatively affected since it only calls excludeFromRecentChanges in loadMetadataBatch (which is just preloading) and getResult (which is called at the last moment so shouldn't affect pagination), and I think RC pagination works differently so this type of issue doesn't apply anyway. But see {T109549}.