daniel added a subscriber: daniel. daniel added a comment. From looking at the code, it should actually be easy to avoid the fatal error without introducing a delay, as the proposed patch does. UpdateRepoOnMoveJob currently works like this:
1. verifyValid() calls normalizePageName(), and //silently// aborts the job if normalization fails (because the page isn't found under the new name for some reason). 2. applyChanges() calls normalizePageName() //again//, making another API call; if that call fails (e.g. because it's hitting another slave, which is more lagged), a //fatal// error is trigged, which lead to the log entry described above. We could just fuse verifyValid with applyChanges, so we only need one API call to normalize the title; if that call fails, we would abort silently, as before. That would fix this bug, as reported: no more fatal errors in the log. However, we should not silently skip updates just because of slave lag. We could just introduce a delay to reduce this issue, or have a way to force the API to query the master database. TASK DETAIL https://phabricator.wikimedia.org/T76545 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: Aklapper, aude, hoo, daniel, Wikidata-bugs _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
