Change Details

If a user with the necessary rights to move the page opens `Special:MovePage` for a page with tens of thousands of subpages, then the page will exceed the maximum request time. ======Steps to re-produce # Log into an account with the `move` right # Find a page with around tens of thousands of subpages which is unprotected or you have the rights to move # Open `Special:MovePage` for this page **What happened:** The request times out **What should have happened:** The page should refuse to display the subpages above a certain threshold to avoid having the request timeout and/or prevent moving the page. =====Extra details The example that I found which prompted me to file this ticket is opening up the move page for https://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations. I had accidentally opened the page at first and wondered why the request took so long (the first request did not timeout but took ages to run). I opened the move page while on `mwdebug2001` and then while I was not on a debug server to get the relevant logstash logs. Both of these requests timed out: * `mwdebug2001`: [[ https://logstash.wikimedia.org/goto/9ac1d9288f1a7fc6051932db08c19b84 | a4c69e43-ae45-4541-adbd-be840b13f718 ]] * Not on a debug server: [[ https://logstash.wikimedia.org/goto/cea6985a91d127cfdfb12a31748d48bf | 9b8e7e41-7954-472b-b41f-3d886e7c1e29 ]] Based on the logs from the `mwdebug2001` request it looks like the cause of the timeout is `LinkCache` as all logstash logs are to do with this class from `09:46:33.961` to `09:47:31.645` (when the timeout occurs). The logs that appear in the debug request say that 960 DB lookups occur because the `LinkCache` does not have the page cached. The last log before the timeout is [[ https://logstash.wikimedia.org/app/discover#/doc/logstash-*/logstash-mediawiki-1-7.0.0-1-2024.02.16?id=sXtPsY0BXQUFBRtCjSPE | this one ]] which suggests that the `LinkCache` was nowhere near the end of the list of pages to process. While the example I found has move protection such that only administrators can load the page, it does not make it unlikely that there are other pages with enough subpages to cause a timeout but do not have move protection. Furthermore, as this is done through a GET request to open a form there is no on-wiki logs that would flag that someone abusing this (instead monitoring logstash would find this).

If a user with the necessary rights to move the page opens `Special:MovePage` for a page with tens of thousands of subpages, then the page will exceed the maximum request time. ======Steps to re-produce # Log into an account with the `move` right # Find a page with around tens of thousands of subpages which is unprotected or you have the rights to move # Open `Special:MovePage` for this page **What happened:** The request times out **What should have happened:** The page should refuse to display the subpages above a certain threshold to avoid having the request timeout and/or prevent moving the page. =====Extra details The example that I found which prompted me to file this ticket is opening up the move page for https://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations. I had accidentally opened the page at first and wondered why the request took so long (the first request did not timeout but took ages to run). I opened the move page while on `mwdebug2001` and then while I was not on a debug server to get the relevant logstash logs. Both of these requests timed out: * `mwdebug2001`: [[ https://logstash.wikimedia.org/goto/9ac1d9288f1a7fc6051932db08c19b84 | a4c69e43-ae45-4541-adbd-be840b13f718 ]] * Not on a debug server: [[ https://logstash.wikimedia.org/goto/5d9be2ee956b2f93778fe4c69329d9ea | 9b8e7e41-7954-472b-b41f-3d886e7c1e29 ]] Based on the logs from the `mwdebug2001` request it looks like the cause of the timeout is `LinkCache` as all logstash logs are to do with this class from `09:46:33.961` to `09:47:31.645` (when the timeout occurs). The logs that appear in the debug request say that 960 DB lookups occur because the `LinkCache` does not have the page cached. The last log before the timeout is [[ https://logstash.wikimedia.org/app/discover#/doc/logstash-*/logstash-mediawiki-1-7.0.0-1-2024.02.16?id=sXtPsY0BXQUFBRtCjSPE | this one ]] which suggests that the `LinkCache` was nowhere near the end of the list of pages to process. While the example I found has move protection such that only administrators can load the page, it does not make it unlikely that there are other pages with enough subpages to cause a timeout but do not have move protection. Furthermore, as this is done through a GET request to open a form there is no on-wiki logs that would flag that someone abusing this (instead monitoring logstash would find this).

If a user with the necessary rights to move the page opens `Special:MovePage` for a page with tens of thousands of subpages, then the page will exceed the maximum request time. ======Steps to re-produce # Log into an account with the `move` right # Find a page with around tens of thousands of subpages which is unprotected or you have the rights to move # Open `Special:MovePage` for this page **What happened:** The request times out **What should have happened:** The page should refuse to display the subpages above a certain threshold to avoid having the request timeout and/or prevent moving the page. =====Extra details The example that I found which prompted me to file this ticket is opening up the move page for https://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations. I had accidentally opened the page at first and wondered why the request took so long (the first request did not timeout but took ages to run). I opened the move page while on `mwdebug2001` and then while I was not on a debug server to get the relevant logstash logs. Both of these requests timed out: * `mwdebug2001`: [[ https://logstash.wikimedia.org/goto/9ac1d9288f1a7fc6051932db08c19b84 | a4c69e43-ae45-4541-adbd-be840b13f718 ]] * Not on a debug server: [[ https://logstash.wikimedia.org/goto/cea6985a91d127cfdfb12a31748d48bf5d9be2ee956b2f93778fe4c69329d9ea | 9b8e7e41-7954-472b-b41f-3d886e7c1e29 ]] Based on the logs from the `mwdebug2001` request it looks like the cause of the timeout is `LinkCache` as all logstash logs are to do with this class from `09:46:33.961` to `09:47:31.645` (when the timeout occurs). The logs that appear in the debug request say that 960 DB lookups occur because the `LinkCache` does not have the page cached. The last log before the timeout is [[ https://logstash.wikimedia.org/app/discover#/doc/logstash-*/logstash-mediawiki-1-7.0.0-1-2024.02.16?id=sXtPsY0BXQUFBRtCjSPE | this one ]] which suggests that the `LinkCache` was nowhere near the end of the list of pages to process. While the example I found has move protection such that only administrators can load the page, it does not make it unlikely that there are other pages with enough subpages to cause a timeout but do not have move protection. Furthermore, as this is done through a GET request to open a form there is no on-wiki logs that would flag that someone abusing this (instead monitoring logstash would find this).