Fri, Jun 11
@Urbanecm can you re-run that last query counting requests made omitting if the api_error_codes field is NULL or not? I’d like to see how those numbers change.
I can’t maybe have it pass back the whole API response ad-verbatim for users to report here. I’m absolutely certain that there is nothing wrong with the OAuth module of the bot, or it’s consumers. The many requests that @Urbanecm listed are from the bot’s main execution workers using the bot’s own owner-only consumer to edit with. These consumers have been largely the same since they were first created, as has been the OAuth engine the bot uses. I’m not convinced that this is something that can be fixed bot wide. As pointed out the API correctly identified the invoking user, and the consumer has all the correct grants selected that are needed to do the job, yet MW opted to error out with a blocked code. 172.16.*.* are likely tool UI invoked requests while the 185.15 one is the bot’s dedicated IP.
The problem is that I remain convinced this isn’t actually an error with the bot, but with the MediaWiki API. These are errors being passed back by the API itself, otherwise it would report a much more descriptive error, and you would also be barred from using the UI itself if you were actually blocked.
Wed, Jun 2
May 6 2021
It's pretty much confirmed that this is not an issue with IABot. After testing multiple scenarios, a user that is legitimately blocked on Wikipedia will receive an entirely different worded error about their block. Specifically, the user will be greeted with "Blocked: You are currently blocked from using this interface. Check to make sure you are not blocked on Wikipedia and/or this interface." The current wording being returned to the user is "blocked: You have been blocked from editing.". This wording is consistent with what the MediaWiki API returns when a user attempts to submit an edit when MW thinks the user is blocked.
Apr 29 2021
It is made very clear to the end user that this is a third party service, and that this service is opt-in. Users are not opted in by default. The use of Hotjar is not new to the admins of Toolforge.
Apr 23 2021
Apr 21 2021
Apr 15 2021
None of those seem to apply as far as I can tell. It’s been discovered that this is only happening on the Kunernetes web service. The grid engine web service works fine.
Oops wrong ticket. This may need some more investigation.
Apr 6 2021
Alright. It will have to wait until I get the DB backend fixed. It's being repaired.
@AManWithNoPlan how would you like to help maintain the data contained within IABot? I can grant you the power to do this yourself going forward? Interested?
When v2.0.9 releases, IABot will no longer read LayURL values in the CS1 templates.
Then what exactly is the lay-url for?
Apr 5 2021
Yes. The DB driving it is currently on fire, so to speak. While I’m putting it out, I had to shut down everything to prevent corruption.
Mar 25 2021
This is implemented in v2.0.9. Use action=runpages to call it.
Your OAuth URL was borked.
This is fixed in v2.0.9 which will be released in a few days.
I need the full list you submitted and the articles that didn't make their way onto the submitted job.
This is fixed in v2.0.9 which will be released in a few days.
This is fixed in v2.0.9, which will be released in a few days.
Mar 22 2021
Is this still happening?
Mar 19 2021
This is related to a component of IABot Green develops.
Mar 18 2021
I see it attached as /dev/vdb but where does it actually mount? Do I have to do that myself?
Mar 12 2021
Is this still happening? I noticed a task that was commented out in my crontab file, was not commented out in the actual crontab.
Mar 5 2021
Hmmm...it’s interesting. Not sure what is happening. Is there a timeframe when this happen? Is it continuous?
Feb 26 2021
It’s hard to tell. It could also be other bots/tools getting blocked at the account level with the anon-flag disabled causing the IP to be effectively be hard-blocked. I don’t know how the inner workings of MediaWiki work. All I know is that this error message comes from the API itself, and not IABot.
Feb 25 2021
These error messages are not originating from the bot, it’s being passed back by the MW API itself when requesting the edit on behalf of the user. All users edit from the IP 18.104.22.168 which is Toolforge. This is either a glitch in the API, or there are admins hardblocking bots originating from it.
Feb 6 2021
I'm hoping this is resolved.
It'll take some time before the backlog of 229 pending jobs are completed.
Feb 2 2021
Yes it turns out the bot had robust error handling for prod errors. It didn’t have robust handling for reused OAuth nonces. For some reason it got a lot of OAuth nonce already used errors. This took repeated running the last few days to diagnose.
Feb 1 2021
Unable to reproduce.
Closing this as resolved as the Wayback Machine has gotten better over the years.
Unable to reproduce. Tool claims you are not blocked.
If you are getting the first error, make sure you are not set to a "Mixed" status. You need to firmly define the state of the URLs. Alive and Dead resets every individual link while Whitelist and Blacklist sets it on all the selected domains as a whole and the bot will no longer assess if they are alive or not.
This does indeed look like a legitimate bug.
You did not whitelist it. No log entry for that URL at all aside from the bot scans it did of it. I have gone ahead and whitelisted it for you.
Jan 28 2021
Timestamps of these entries seem to suggest that when the bot encounters these failures almost all API requests being made are erroring out during the timeframe of these batch errors.
Got an influx of blank, 500s and 502 overnight. Your errors may be "few" overall, but they are happening in batches.
Jan 27 2021
Normalization is by default on, but can be turned off if the community wants it off.
I've added additional logging data to the framework.
Got another surge of bad responses from production.
Joe, not all requests are 502s. They are insignificant compared to the amount of requests returning null responses. This is a very problematic occurrence as Cyberbot has begun to malfunction badly because of it. Is blanking pages repeatedly, my talk page is littered with malfunction reports. Granted some extra robustness could be implemented, this shouldn’t have to be something I would need to guard against at this level. Cyberbot has never had these problems in the past until I started getting reports around 11 days ago. I see my communication log is starting to grow to a large size recording these failures and has grown to 5 GB.
It won’t. It’s not designed to do that. It will only recognize the alias and use what’s there, or add the default preferred alias if not defined.
Jan 26 2021
No changes have been made to the bot whatsoever.
The IP 172.16.2.21, I don't know what the UA is. The bot is pretty old.
Jan 25 2021
Jan 7 2021
Dec 29 2020
Project Name: cyberbot
Type of quota increase requested: 8 CPUs and 16 GB RAM
Reason: IABot is expanding on to more WMF wikis, which requires more processing power. The current exec VM is reaching its limit.
Dec 11 2020
Especially to Wikidata.
Thursday, as in yesterday? I’m not aware of anything that should have been running to create that massive level of requests.
Dec 6 2020
I don’t have access to your Citation module on ruwiki. A local sysop will need to make the changes.