Change Details

From T261189: The pre-existing issue is that the list of wikis include test.wikipedia.org. This is a special wiki where CX has been configured to "translate in the target", but still used the shared, global database tables. This means that when the loop gets to testwiki, the purge script detects this condition and instead of only going over drafts *->testwiki (I guess en, but doesn't matter), it goes over all drafts and purges and notifies them. So for any wiki that appears after testwiki in the list, our script would not do anything, since testwiki already went over them. To make things worse, the purges for testwiki succeed, but any notification will fail (because it would need to send the notification to an user in another wiki). Suggested fixes: * [] Immediately remove testwiki from the script runs * [] Setup CX on testwiki so that it does not used the shared database tables, but instead of a local copy of the tables. If this is done, testwiki can be restored on the script runs. ** [] Remove testwiki from extension1 cluster. ** [] Create CX tables on testwiki.

From T261189: The pre-existing issue is that the list of wikis include test.wikipedia.org. This is a special wiki where CX has been configured to "translate in the target", but still used the shared, global database tables. This means that when the loop gets to testwiki, the purge script detects this condition and instead of only going over drafts *->testwiki (I guess en, but doesn't matter), it goes over all drafts and purges and notifies them. So for any wiki that appears after testwiki in the list, our script would not do anything, since testwiki already went over them. To make things worse, the purges for testwiki succeed, but any notification will fail (because it would need to send the notification to an user in another wiki). Suggested fixes: * [x] Immediately remove testwiki from the script runs * [] Setup CX on testwiki so that it does not used the shared database tables, but instead of a local copy of the tables. If this is done, testwiki can be restored on the script runs. ** [] Remove testwiki from extension1 cluster. ** [] Create CX tables on testwiki.

From T261189: The pre-existing issue is that the list of wikis include test.wikipedia.org. This is a special wiki where CX has been configured to "translate in the target", but still used the shared, global database tables. This means that when the loop gets to testwiki, the purge script detects this condition and instead of only going over drafts *->testwiki (I guess en, but doesn't matter), it goes over all drafts and purges and notifies them. So for any wiki that appears after testwiki in the list, our script would not do anything, since testwiki already went over them. To make things worse, the purges for testwiki succeed, but any notification will fail (because it would need to send the notification to an user in another wiki). Suggested fixes: * [x] Immediately remove testwiki from the script runs * [] Setup CX on testwiki so that it does not used the shared database tables, but instead of a local copy of the tables. If this is done, testwiki can be restored on the script runs. ** [] Remove testwiki from extension1 cluster. ** [] Create CX tables on testwiki.