In T322916#11267175, @Reschultzed wrote:

Judging by the discussion at WT:TWL, access to newspapers.com is not currently working. I thought it was happening to me only because my annual renewal period had come up (and incidentally, it would be great if users could be notified when their access to a resource is about to expire so we can renew it as promptly as possible), but other users whose renewal isn't for months yet say they're having the same problem. I don't know if this is the best place to ask, but can someone look into this?

I think that there might be some confusion as to using the backend for the NP proxy login. It has worked for me when I am simultaneously logged into NP proper and the cookies are directly copied over into the proxy; this includes the duration date especially. If the login session on NP ends, as in a timed sign out after a month or so, you HAVE to do the process over again, which isn't terribly hard, but that's solely because the cookies need to be in sync with each other.

In T322916#10063620, @mxn wrote:

Searches are working for me. I’m still unable to log in with my personal account through the proxy due to the CloudFlare error I mentioned earlier. Fortunately, I seem to have a workaround in Firefox:

1. Log into Newspapers.com through the official site.
2. Open the Storage tab of developer tools and copy the values of the user_data and user_token cookies, as well as their expiration dates.
3. Go to www-newspapers-com.wikipedialibrary.idm.oclc.org and clear all cookies and local storage associated with the site.
4. In the Storage tab of developer tools, add new user_data and user_token cookies matching what you copied from Newspapers.com.

This worked well enough for me to create a clipping (view without proxy).

I am truly hoping this is not because of an exploitable bug in the Newspapers.com backend because that would concern me an awful lot.

In T322916#10036209, @Samwalton9-WMF wrote:

We're starting to discuss this with Newspapers.com, but it's going to be the hardest one to move back off of proxy-based access because it's had somewhere in the region of 1,500 users in the past 6 months. That would be a large workload for Newspapers.com to set up individual accounts for, so we're going to need to explore our options with them.

Let me just reiterate that it would be much, much, MUCH more effective to scrap the ezproxy and return to the old method of emailing TWL for year-long passes to Newspapers.com. At least that was reliable and worked consistently!

The logging out, BTW, is not universally applied; for some reason, I am still logged in to the NP ezproxy on one laptop even after my primary and secondary laptops bounced me out.

Add me to the chorus of people who want the old system back ASAP. To be blunt, the ezproxy is a failure and needs to be scrapped; it is disappointingly clear that it cannot work at all on Newspapers and is impairing my efforts on Wikipedia substantially. Extremely disappointed.

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).

In T321740#8511713, @Cyberpower678 wrote:

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

I am sorry; my brain is too wired to think “EOD” as “end of business day”, not the literal end of the day.

Being promised that something will happen at X time and failing to deliver on the promise is just as bad as not communicating with anyone in the first place. In all seriousness, is this truly a problem beyond everyone’s control and the bot just cannot be fixed? If I have to literally archive my refs manually going forward then at least just say so.

Honestly, I’ll believe it when I see it. The prolonged failure to communicate has been frustrating and aggravating, and only lends me to be skeptical and pessimistic that the bot will ever be fixed.

The bot is still broken on enwiki after more than two months. Even if the problem hasn’t been worked on, a status update or a mere acknowledgment that the problem exists would be quite helpful. This continued radio silence is honestly very unacceptable and I am profoundly disappointed in this repeated failure by the maintenance team to communicate. Even if the bot was somehow fixed I wouldn’t want to run it.

In T321740#8411252, @Harej wrote:

I am sorry for the delay as we needed to track down the underlying issue. What is happening is that our system for identifying templates is growing unexpectedly large in size, and this causes the interface to break down. First we need to identify the source of this "leak," and then we need to clear out our template database. The interface will remain unavailable while we work on this.

Expanded on from the IABot talk page section on Wikimedia, which itself has gone fallow with no updates:

For the record, I just executed the bot on a page I knew had bare URL refs; six were archived. Four were converted to a CS1 template, while two had the Webarchive template appended to them.

So this attached image (h/t @Chlod from the Wikipedia Discord) was mentioned on the bot talk page on WikiMedia proper but AFAIK has not been on the actual ticket here. IMO this is a VERY critical problem. Either it's a major database cache issue on InternetArchive's end, IA's databases ran out of space, or something altogether different.

Looking at the existing output from https://en.wikipedia.org/wiki/Special:Contributions/InternetArchiveBot it looks like some very very very large queue in alphabetical order was executed that is basically preventing almost anything else from being processed.

Here is a screenshot of my false positives. It always times out for me between 4-10 seconds regardless of what I do. This has been going on for the past two weeks.