An important distinction to be made with Event Metrics – ultimately the "report" data in Event Metrics gets pre-stored in a database, indefinitely. This isn't a problem in terms of storage because they are just numbers. In addition, Event Metrics had a timestamp of when the report was generated, and you as the user will always get that version of the report until you ask for an updated version. In our case, we end up with a epub (or other format), which is not as cheap to store, and also we want to automatically ensure the user is served the latest possible version. So the two systems won't work exactly the same.

In T265430#6557099, @bd808 wrote:

There'll have to be a limit to this before it gives up, since I assume in future-proofing there could be any number of instances that a connection could be assigned to.

Today the "worst case" could be 3 servers in the round robin pool, but much more likely to be 1-2. In the not too distant future, the worst case could go up to 8 servers in the pool, but 2 will be more likely. Opening a connection to the db server and asking it to return @@GLOBAL.hostname should be extremely fast. I agree that you should put an upper limit on retries, but I would let it be relatively large (like 100) before a hard stop.

I think this and T262631 are the only tasks in the AutoEdits column that aren't about updates to semi_automated.yml. I've no reservation against a new column (or a project), but I still don't think it would solve much. I have begun preliminary work on T262631: Move AutoEdits configuration to on-wiki JSON pages which will move the burden of updating to the community and make the new column/project redundant. That will take a good while to complete with my current workload, probably a few weeks.

Hmm, that's a pity! But I understand load balancing is more important than sql-optimizer :)

Task for caching credits info: T265660

For some reason I was under the impression that you needed a NDA to be able to access a VPS.

Thanks for reporting this. The old link should now work (but you may need to clear your browser cache first).

In T265431#6541365, @dmaza wrote:

In T265431#6541353, @Samwilson wrote:

Yes, that's a very good point, I was wondering that too. After T261480 we can look at the user agents more easily; should this task wait till that's done?

Also, are we allowed to log user agents? Aren't they sort of user-identifing?

This is tricky and I do not know the answer. AFAIK you can log that kind of data as long as it has a 90 days TTL and it is only available to users with a NDA. Technically, user-agent is already stored in the server so anyone with sudo access to the VPS can see it (which is fine 'cause you sign an NDA to get access)
aezell Niharika you've recently dealt with this in Checkuser/IP-Info/etc; could you provide more info?

@dom_walden Ready for QA again! I thought I'd ping you since this was incorrectly in your column for almost 2 months... now it's intentionally there :)

In T201193#6507200, @Daimona wrote:

In T201193#6507181, @Daimona wrote:

Hmm, it's not the first time I see it, but it always passes locally. Given what the test does, my guess is, it tries clicking the "submit" button before it works. This is not 100% convincing because the button is not JS-enriched etc., but perhaps it's worth trying. As anticipated, I cannot tell whether the fix will work because I don't get a failure locally (not even if I delay the page load).

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/631311

This is now live. Maintainers of CopyPatrol should get an email when there are no cases younger than 4 hours old. @Diannaa you no longer need to ping us, but I'm not saying you can't, because of course you still can :) I should also point out that it seems you work on a slightly earlier schedule than most of us here at CommTech, and historically by the time I wake up the bot had fixed itself. But at least now we have some automation in place and may be able to catch things earlier. The next step obviously is to figure out why it keeps going down and what we can do to mitigate it. More on that soon, I hope!

Looks like activity has long since resumed. I'm happy to report, by the way, that our monitoring of the feed (T262767) will be deployed soon, and you will no longer need to inform us when there is no activity :)

Resolved per T264823

This is live on the staging tool. There are two URL params that can be passed, lang (default en) and offset (default 4), where offset is the number of hours.

PR: https://github.com/wikimedia/CopyPatrol/pull/90

Okay, glad to hear it is working! If you ever are convinced there is an issue, do please feel free to create a new task. Thanks!

I suspect some sort of maintenance on testwiki_p, similar to T210978. I've filed T264823.

For some quick numbers, I looked at the month of September 2020:

In T261030#6511865, @dom_walden wrote:

If the same page is watched permanently. Submitting an API request with watchlist=nochange and no expiry set:

{
    "edit": {
        "result": "Success",
        "pageid": 229559,
        "title": "Test123454",
        "contentmodel": "wikitext",
        "oldrevid": 453697,
        "newrevid": 453698,
        "newtimestamp": "2020-10-02T09:22:38Z",
        "watched": true
    }
}

Note it does not return a watchlistexpiry. @ifried @MusikAnimal Perhaps it should state that watchlistexpiry: infinite, like we did previously.

This also happens if I choose to watch and set the expiry to "infinite" (e.g. https://en.wikipedia.beta.wmflabs.org/wiki/Special:ApiSandbox#action=edit&format=json&title=Test123454&watchlist=watch&watchlistexpiry=infinite)

@Kizule Where do we stand with the bot? I see now it has edited numerous times: https://sr.wikipedia.org/wiki/Special:Contribs/Community_Tech_bot. Does these look correct to?

In T256501#6511243, @eranroz wrote:

Following a recent change all users where forced to logout - https://lists.wikimedia.org/pipermail/wikitech-l/2020-October/093922.html
I had to relogin to set the session again - it should start to work soon

Still no new reports, and iThenticate links are failing to load. I wonder if we are out of credits at the Turnitin service?

In T263515#6509612, @Kizule wrote:

@MusikAnimal I think that here should be added alias: sr -> sr-ec.

Pull request: https://github.com/wikimedia/CommonsNotifier/pull/15

In T263515#6509551, @Kizule wrote:

@MusikAnimal Serbian language have two variants: Cyrillic (sr-ec) and Latin (sr-el). In configuration, sr fallbacks to sr-ec. And translating on translatewiki.net for sr is disabled because of these reasons.

It's merged now, we can iterate on it as necessary. I see dmaza moved this task to the Done column so I'll mark it as resolved.

How about "Wikisource Download"? So the proxy name could be ws-download.

I've restarted the bot, we'll see if that does anything. As for buttons not working, I suspect that was related to the general instability of Toolforge we've been experiencing the last few days, see https://stats.uptimerobot.com/BN16RUOP5 (the only tools at 100% uptime are on VPS, not Toolforge).

In T261030#6506204, @MusikAnimal wrote:

I don't think we should continue using the service locator if we don't have to, especially if it's just to accommodate an unmaintained extension. Hacking LiquidThreads seems acceptable to me. What do you think dmaza ? See LiquidThreads patch at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/LiquidThreads/+/631219/

Merged and deployed, now waiting for the bot to edit https://sr.wikipedia.org/wiki/Special:Contribs/Community_Tech_bot

In T261030#6506111, @Ammarpad wrote:

The page needs rewrite. But any significant rewrite even for supported extension would really take time. But LiquidThreads is essentially dead and ought to be undeployed T187487.

I initially intended to use the service locator in the trait, but there's was some objection. The services is already being used in the ApiEditPage to fetch RevisionLookup and I am not sure why we should not use that to fetch a single WatchedItemStore. At any time when LiquidThread is rewritten or the extension gets undeployed, the ApiEditPage can inject both the WatchedItemStore, RevisionLookup and other dependencies that it's currently getting from service locator, such as ContentHandlerFactory,

Could we solicit some help to get LiquidThreads fixed?

@L.d.men Hallo. Hier melden Sie Softwarefehler. Wir sind uns nicht sicher, wovon Sie sprechen, aber es scheint nicht um XTools zu gehen. Entschuldigung, wir können Ihnen nicht helfen.

Wonderful! Closing as resolved.

Not an issue with the Pageviews tool, rather the data that it serves. Anyway I agree that this is most surely a bot.

With 1.35.0 shipped, I think we can close this.

Well that didn't take long: https://ar.wikipedia.org/wiki/Special:Diff/50662771

@alanajjar Apologies for the long wait! This has now been deployed. We will be keeping an eye on Special:Contribs/Community Tech bot. Let us know if something looks off, or if the bot failed to edit when you think it should have.

PR: https://github.com/wikimedia/CommonsNotifier/pull/12

In T256527#6488782, @MarcoSwart wrote:

@MusikAnimal Happy to inform you that the bot today made its first edit. Everything worked as expected, and I could simply replace the picture before it probably will get removed.

See also T258098: Purge unused watchlist rows which should fee up a sizable amount of space in the watchlist table (depending on the wiki), and has some ideas about future-proofing. I believe this is a worthwhile pursuit regardless of what happens with watchlist expiry.

Note also the dropdown itself either needs to be full-width or centered.

It turns out the job on Toolforge was stuck. I restarted it and the bot is now editing other wikis. By all indications it should be running on nl.wiktionary too, only it hasn't encountered a file used on nl.wiktionary yet. I'll continue to monitor.

In T256527#6457759, @MarcoSwart wrote:

@MusikAnimal : It is now nearly two months since you moved this task to "Needs Review/Feedback". Nothing seems to happen. What's wrong?

To have it trigger alerts when no new entries are detected since some time, you can add a special endpoint in the webservice to serve GOOD or BAD keywords. This healtcheck would be defined by sql query "does there any new entry in last 4 hours for each wiki"