PR for deleting TWLight sessions for deactivated users is ready for review:
https://github.com/WikipediaLibrary/TWLight/pull/1323

PR for search script ready for review:
https://github.com/WikipediaLibrary/OCLC-EZproxy-Analysis/pull/1

@Scardenasmolinar
it looks like we're calling equals() on the return value of getUser() without checking to see if it actually returned a user. That seems like the most likely cuplrit:
https://codesearch.wmcloud.org/things/?q=equals&files=%5Esrc%5C%2F.%2B%5C.php%24&excludeFiles=&repos=Extension%3AAutoModerator

In T370161#9987811, @Dogu wrote:

Done! @jsn.sherman

Since this is happening in the revision precheck, it, we should be able to stop the error immediately by disabling automoderator here:
https://tr.wikipedia.org/wiki/MediaWiki:AutoModeratorConfig.json
that would be something that @Dogu or another interface admin could do while we get a patch out

awaiting deployment on next train

If someone can rename:
https://en.wikipedia.beta.wmflabs.org/wiki/User:Jsn.sherman_beta/sandbox3
into the main name space on beta we can verify the fix there.

We've been unable to reproduce this locally, but we did reproduce it on enwiki beta. I suggest merging and retesting on beta.

@Dzahn I'm happy to sponsor @Soda on this one; apologies for the delay!

Counters like that could be used to populate the landing page T360127: Determine what data to surface on Automoderator's landing page

In T360695#9828911, @Samwalton9-WMF wrote:

@jsn.sherman Is this still necessary, or does Logstash serve this purpose now?

It looks like they have updated their site enough to require a config update. This configuration is provided by oclc, so I've opened a ticket with them to request an update.
For reference, this is the oclc-managed configuration:
https://help.oclc.org/Library_Management/EZproxy/EZproxy_database_stanzas/Database_stanzas_M/Mohr_Siebeck

In T366978#9961519, @Scardenasmolinar wrote:

There was still duplicated data on some tables.

scc output for the watchlist files:

I ran an scc analysis for the files you mentioned in ./includes/changes

@sjvipin I've answered the questions to the best of my ability; do you have any questions?

In T361692#9949841, @DMburugu wrote:

@jsn.sherman Is this something that needs to be followed up soon or it can wait since we're already live on trwiki?

unique ezproxy users by domain and host between 2024-01-01 and 2024-06-30:

• newspapers.com: 1518

In T367865#9943605, @sjvipin wrote:

@jsn.sherman - The difference between number of Wikipedia articles and number citations is that one Wikipedia page might have multiple citations to BOA so that number could be higher.

ideally, I would like to get a table with the list of citations links and Wikipedia articles made by these 352 unique users https://microform.digital/boa/collections

@sjvipin from 2024-02-01 to 2024-06-30, BOA had 352 unique library users.

@sjvipin I'm working on the proxy numbers right now. Could you explain the difference between these two requested data points? They seem the same to me:

@Kgraessle let's put a pause on this while @sjvipin talks with the partner about the options of whitelisting recaptcha or switching to voucher codes instead of proxy.

@sjvipin ezproxy is not compatible with google recaptcha; we'll need to ask them to disable it for the proxy IP address.

@sjvipin could you reach out on the partner side to request disabling of captchas for Corriere Della Sera and Corriere Della Sera Archives?

In T345104#9932816, @Kgraessle wrote:

In T345104#9932186, @jsn.sherman wrote:

@Kgraessle
Can you please share a WIP github PR with the ezproxy config changes you were testing to get these results? It's okay if some parts are commented out (with notes) if you tried a few different things.

In T345104#9931542, @Kgraessle wrote:

Adding login flow to corriere

Navigate to the Access collection button in staging for Corriere Della Serra archives and update the parameter URL to point to the login URL. Update the landing page to be our proxied URL.

<a href="https://wikipedialibrary.idm.oclc.org:9443/login?auth=staging&amp;url=https://www.corriere.it/account/login?landing=https://wikipedialibrary.idm.oclc.org:9443/login?auth=staging&amp;url=https://archivio.corriere.it/" class="btn btn-sm twl-btn access-apply-button" type="button" name="button" target="_blank" rel="noopener">
   Access collection
</a>

This will take you to a page that is proxied for the login flow. When I try to set the landing parameter to anything that isn't their domain (our proxy URL) then it won't let me sign in. The button is disabled and stops me from continuing through the flow.

I would expect that there is javascript validation happening to do that disable, which you would also need to capture with a rewrite rule to amend the allowed domains/hostnames. I'm surprised that the login url is being used here instead of the proxied endpoint( eg. https://archivio-corriere-it.wikipedialibrary.idm.oclc.org:9443)

If I add the landing parameter to be

<a href="https://wikipedialibrary.idm.oclc.org:9443/login?auth=staging&amp;url=https://www.corriere.it/account/login?landing=https://archivio.corriere.it/" class="btn btn-sm twl-btn access-apply-button" type="button" name="button" target="_blank" rel="noopener">
   Access collection
</a>

Then the flow continues to the site https://archivio.corriere.it/ without being proxied.

Unfortunately none of the config I updated was helpful, it's also hard to tell when the config goes out so it's been a bit tedious trying to test config without knowing if it's actually deployed or not.
I don't really have anything substantial to commit as a result.
I can tell you that my initial thoughts are that the image is being corrupted when the content provider is sending the data to the ezproxy server:

Because we know the images are being proxied correctly from the network tab request.

PR merged; we have deployments paused for wikilink, so this won't show up for another day or two. I'll post an update once it's ready for QA.

This looks great; thanks for your work @Kgraessle!

@Kgraessle
Can you please share a WIP github PR with the ezproxy config changes you were testing to get these results? It's okay if some parts are commented out (with notes) if you tried a few different things.

@Dogu
It looks like Otomoderatör has done it's first revert (it's a pending edit that wants to revert a pending edit, anyway)
https://tr.wikipedia.org/wiki/%C3%96zel:Katk%C4%B1lar/Otomoderat%C3%B6r

@Dogu we believe we have this sorted out; could you re-enable automoderator on trwiki? We'll be monitoring for errors.

it would also be worth logging a warning

In T360136#9904773, @Kgraessle wrote:

If for some reason an admin changes the config to a value that doesn't map to a caution level, which caution level do we want to fall back on?

So far, it looks like there have been no more occurrences of this error on testwiki since 1.43.0-wmf.10 rolled out to it.

In T351860#9899316, @jsn.sherman wrote:

I was able to warm the cache by reloading the page a few times, but it shows that there are 0 current total links, which seems pretty unlikely:

! In T351860#9900266, @jsn.sherman wrote:

ah, it looks like something happened (or didn't happen) at the turn of the year:

ah, it looks like something happened (or didn't happen) at the turn of the year:

In T367000#9887002, @Jdlrobson wrote:

This looks like it got fixed by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1041782

I was able to warm the cache by reloading the page a few times, but it shows that there are 0 current total links, which seems pretty unlikely:

noting that we are missing translations for the privacy policy link
https://translatewiki.net/w/i.php?title=Special%3ATranslate&group=ext-wikimediamessages&language=en&filter=&optional=1&action=translate

It looks like this is still a problem with JSTOR

those things are now done! staging is up at https://twlight-staging.wmcloud.org/

I updated the script and used it to deploy a new TWLight staging environment:
https://github.com/WikipediaLibrary/TWLight/pull/1305

The simplest change we could make besides doing lazyPush is to allow retries when we encounter this.

A few notes:

We'll be monitoring impression and submission count to see if we need to adjust the sampling count over time.

I switched over to lazy push for the job queue insert. I experimented with adding a release timestamp, but that seemed to break things in mediawiki-docker, eg. No jobs were queued at all that way.

These warnings coincide with an Automoderator error in a job which we fire off a job in RevisionFromEditComplete. The hook handler passes the revision id as a parameter to the job. The job does a lookup for that revision id, and that lookup often comes up empty. Spot checking page history shows that these revisions do (at least eventually) exist. Is our job doing a revision lookup on a stale/bugged cache in these cases? Is the jobrunner hitting a db host endpoint that hasn't achieved write consititency? I'm wondering if these two issues have a shared underlying cause.