operator: 7804jPosted 10/28/2026, 7:51:08 PM UTCLanguage: en
Good question. There is no job at all, and no stored flag. The status is computed on demand, inside the request that needs it: deciding whether to show or allow Roll back, saving a page protected for experienced editors, and showing the status in the user-rights tool. It's one query over pages, citations, claims and page checks, stopping at five lasting edits. Admin overrides are a one-row-per-user table, checked first.
Checking this, I found the query had no index by author on those tables. #101 will add them (author + date), and reuse the result within a request. The technical notes now say all of this.
operator: 7804jPosted 10/29/2026, 9:23:23 AM UTCLanguage: en
Done: #101 now has a "Performance" section. It lists which routes run the check and when, with timings on a local database of 126k page revisions.
Measuring it showed the first version was too slow: 55–320 ms per call, even with the new indexes. It joined every revert to every page revision on each call. Commit 6936030 fixes that. Each table now reads only the person's oldest five edits in index order, and the revert check only reads the edited page's revisions. A call now takes 0.1–0.6 ms, with the same results. The worst case I found: someone with 2,000 old page edits that were all reverted, about 70 ms.
Signed-out readers never run it. On article views it only runs on pages protected at the "experienced" level.
Good question. There is no job at all, and no stored flag. The status is computed on demand, inside the request that needs it: deciding whether to show or allow Roll back, saving a page protected for experienced editors, and showing the status in the user-rights tool. It's one query over pages, citations, claims and page checks, stopping at five lasting edits. Admin overrides are a one-row-per-user table, checked first.
Checking this, I found the query had no index by author on those tables. #101 will add them (author + date), and reuse the result within a request. The technical notes now say all of this.
— Claude (AI assistant working with @jz7804)
OK, in that case the PR should include a performance analysis of the per-view impact on the affected routes.
Done: #101 now has a "Performance" section. It lists which routes run the check and when, with timings on a local database of 126k page revisions.
Measuring it showed the first version was too slow: 55–320 ms per call, even with the new indexes. It joined every revert to every page revision on each call. Commit 6936030 fixes that. Each table now reads only the person's oldest five edits in index order, and the revert check only reads the edited page's revisions. A call now takes 0.1–0.6 ms, with the same results. The worst case I found: someone with 2,000 old page edits that were all reverted, about 70 ms.
Signed-out readers never run it. On article views it only runs on pages protected at the "experienced" level.
— Claude (AI assistant working with @jz7804)