The 503 errors and DB ERRORs you've been getting were unrelated issues.

I'm not aware of any issues that should prevent the bot from doing what it's supposed to do. At this point, this ticket is merely addressing a major performance penalty the bot is currently incurring as a result of the bug regarding data ingesting.

This should be fixed hopefully today.

In T326609#8515415, @Marshelec wrote:

It worked ! It has successfully analysed the article: Tellico Dam where it was previously failing. It analysed 44 links, rescued 40, and added 12 archives. It took 703 minutes to run (longer than I would have expected prior to the recent problems), but it worked :). I have yet to check through the archives, but they look good in a quick inspection. Many thanks, M

In T321740#8515333, @Aoidh wrote:

It works for me when I just checked it. I ran it again on a page that earlier today brought me to a blank white page the way SunDawn described but now works: https://en.wikipedia.org/w/index.php?diff=prev&oldid=1132886366

In T321740#8515257, @SunDawn wrote:

Thank you for your work, but the tool broke again. The browser only displayed an empty page when the "Analyze" button is clicked.

In T326609#8515315, @Marshelec wrote:

Thanks, I just tried to analyse the article Tellico Dam again, but no good - same message about missing token. If I understand your comment about a Bot job correctly, it refers to scheduling in a queue ? I have set up a queued job for this article to see if that does the trick.

IABot has been whitelisted on CloudFlare.

You get that error when you refresh the UI on any action request without resubmitting form data. The tool uses tokens and checksum hashes to ensure requests are not accidentally repeated, and that malicious users can't exploit any CSRF vulnerabilities. In short, they're security features meant to keep you safe. All you need to do is click the submit button again when that happens.

Alright, give it a try now.

What's happening here is because the bot is taking longer to work on the article, it's hitting the server-side execution time limit and timing out. Ordinarily large articles are blocked from even running on the tool, where the user is instead directed to running a bot job instead with the desired article(s). I can try to push the time limit a little higher to get around this, but this will only be temporary. The limit exists to prevent rogue processes from indefinitely hanging up a connection resource, that would end up blocking someone else from using the tool.

If you want to follow the progress on getting the underlying issue fixed, you can subscribe to T326609

In T321740#8512577, @Nathan_Obral wrote:

Cyberpower, I apologize for being cross and angry the past few weeks. You kept your word and fixed it by EOD Monday. The bot largely works although it does time out on a few pages (but that could be a browser cache issue on my end).

Again, I apologize for the angry tone of my posts in this thread. The issue is fixed and again you kept your promise to fix it. Thank you and cheers.

There we go. It's EOD, Monday. Just as promised. Sorry for the wait. Tool should be working now.

Hey guys, sorry for the silence. I've been trying to get at the root of the issue which is not an easy thing to do since the culprit is being caused by an over-ingested amount of data in the bot's configuration when it comes to handling CS1 templates. Since this has been dragging on for so long, I am instead now putting in a work-around which will be a fail-safe if this root issue happens again. Expect it to be available by EOD, Monday.

Code is being tested.

It is clear that the operators of archive.ph have no interest, or ability, to address the issue with IABot not being able to communicate with their servers. A workaround, that doesn't require users to clean up after the bot, or appease the bot needs to be implemented in the bot code.

This is an issue with archive.today. Please use the long-form versions of archive.today snapshots.

https://github.com/chrome-php/chrome/issues/444

Reverted to Grid engine as Kubernetes appears to return a 503 after some hours.

Actually this level of protection has been successfully broken. Chromium not needed here.

A profile to localize the months in uz already exists in the code.

https://github.com/wikimedia/DeadlinkChecker/pull/50

https://github.com/wikimedia/DeadlinkChecker/pull/50

Turns out while IABot could have used better HTTP/2 handling, this appears to be very very sophisticated CloudFlare protection, that is able to distinguish cURL requests from actual browser requests even if a perfectly imitated browser-generated cURL request is made.

https://github.com/internetarchive/internetarchivebot/pull/91

The bot could have archived it, but was prevented from doing so with the new configuration option.