XZise added a subscriber: Ladsgroup. XZise added a comment. Okay after today a third one reported exactly the same issue, I was able to work with them to actually check what is happening. The script in https://phabricator.wikimedia.org/P1892 is basically replicating what is happening but actually patching some parts to get the vital information. When executing the script https://phabricator.wikimedia.org/P1893 shows that it first loads the `query` modules using `paraminfo` as that is using `querymodules` and @jayvdb is using that as a hack to get to the `query` modules without actually querying the `query` module. That information is from July 25th. Then it queries the `query` module to get its submodules (like in the traceback of the opening post) and it assumes that the `query` modules are only there when the `query` module was actually fetched (which was until now not the case) so it fetched them but that information is from Aug 15th. And that version is now supporting one additional submodule (`flowinfo`). So the only bit left is to verify that the submodule was actually added somewhere in that range.
My patches (https://phabricator.wikimedia.org/rPWBC424eaa3532b6e62c53edcb0eebca58dea0cefaeb and https://phabricator.wikimedia.org/rPWBC8f2fba2bf65947a849175c8ca95901cf15b9f4a2) might have highlighted this issue as they changed the order in which the requests are done and they were done in the time range mentioned. As all three cases were on toollabs maybe @Ladsgroup knows when it's updating the nightly (which is afaik what is used then). In the last case the bot is executed at 05:00, 13:00 and 21:00 UTC so when it builds the version somewhere between 21:00 UTC and 05:00 UTC it may be really https://phabricator.wikimedia.org/rPWBC424eaa3532b6e62c53edcb0eebca58dea0cefaeb as it was merged Fri Aug 14 14:42:05 2015 +0000 and the first run on Saturday was failing. In the end the problem is simply that our API cache may just contain inconsistent information and paranoid as I am I added asserts which are detecting that and thus fail. There are two proper fixes for this: - Ignore that assertion and hope there is no inconsistency - If it detects an inconsistency it invalidates all caches for that site with `action=paraminfo` and re-initialize it Anyway I opened it again because reverting my fix is only hiding this issue and not actually solving anything. For now cleaning the cache works. In theory it's possible to write something for the maintenance script to just clean those. For example to print the `paraminfo` calls to the Commons (+the cache date/time): python pwb.py scripts/maintenance/cache.py -c "print(entry._uniquedescriptionstr() + '\n{0}\n'.format(entry._cachetime)) if 'Site(\"commons\", \"commons\")' in entry._uniquedescriptionstr() and 'paraminfo' in entry._uniquedescriptionstr() else None" TASK DETAIL https://phabricator.wikimedia.org/T109168 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: XZise Cc: Ladsgroup, JAnD, XZise, jayvdb, gerritbot, Xqt, Aklapper, pywikibot-bugs-list, Billinghurst, Malyacko _______________________________________________ pywikibot-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/pywikibot-bugs
