recaptime.dev / phorge
@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.) hq.recaptime.dev/wiki/Phorge
phorge phabricator
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

Correct the interaction between overheating and offset-based paging

Summary:
Ref T13386. If you issue `differential.query` with a large offset (like 3000), it can overheat regardless of policy filtering and fail with a nonsensical error message.

This is because the overheating limit is based only on the query limit, not on the offset.

For example, querying for "limit = 100" will never examine more than 1,100 rows, so a query with "limit = 100, offset = 3000" will always fail (provided there are at least that many revisions).

Not all numbers work like you might expect them to becuase there's also a 1024-row fetch window, but basically small limits plus big offsets always fail.

Test Plan: Artificially reduced the internal window size from 1024 to 5, then ran `differential.query` with `offset=50` and `limit=3`. Before: overheated with weird error message. After: clean result.

Maniphest Tasks: T13386

Differential Revision: https://secure.phabricator.com/D20728

epriestley f1b054a2 5741514a

+4 -1
+4 -1
src/infrastructure/query/policy/PhabricatorPolicyAwareQuery.php
··· 233 233 // number of records when the viewer can see few or none of them. See 234 234 // T11773 for some discussion. 235 235 $this->isOverheated = false; 236 - $overheat_limit = $limit * 10; 236 + 237 + // See T13386. If we on an old offset-based paging workflow, we need 238 + // to base the overheating limit on both the offset and limit. 239 + $overheat_limit = $need * 10; 237 240 $total_seen = 0; 238 241 239 242 do {