It was sent. (It's important to note this is different from whether the receiver wants to receive it or not)

Just processed those edit requests.

I think this is related:

ERROR: TjfCliError: The jobs service seems to be down – please retry in a few minutes.
ERROR: Please report this issue to the Toolforge admins if it persists: https://w.wiki/6Zuu

FYI: log entries with an associated VRTS ticket seem to be misformatted: see e.g. https://meta.wikimedia.org/w/index.php?title=Special:Log&logid=57074693. I presume there should be a number there (not XXXXXXXXX), and the link format should be more like that which would be produced by printf("per [[:m:Right to vanish]] and [[:ticket:%s|ticket %s]]", ticketNumStr, ticketNumStr) (not printf("per [[:m:Right_to_vanish|m:Right_to_vanishandticket]][[:ticket:%s]]", "XXXXXXXXX"))

I was just able to reproduce something related, but the output was slightly different, and the config file seems intact. See P67493.

@Marostegui Given that the issue has been identified (and only trusted users have/had the higher rate limits), can this be made public again?

Ran into this issue again. I'll have a go at this.

In T343131#9626539, @LucasWerkmeister wrote:

In T343131#9625722, @gerritbot wrote:

Change 991921 merged by jenkins-bot:

[mediawiki/extensions/WikimediaMessages@master] Use interwiki to link to Creative Commons

https://gerrit.wikimedia.org/r/991921

Once this rolls out with the train next week, the number of external links to https://creativecommons.org (currently 146759278, or ~146.8 million) should start to go down gradually, as pages are re-parsed for various reasons and use the new version of the message with an interwiki link instead of an external link. (But we might have to actively mass-purge pages to get all of them to switch to interwiki links.)

Totally forgot about this task, but I did this a while ago.

Just found T298672, which this is a duplicate of.

In that case, I'm not interested. Thanks for looking!

This is still happening as of now. In case it helps to have a second log entry, here you go: [345c9f98-01ab-4ba9-b82b-21e2bd831c42] 2024-06-14 23:35:14: Fatal exception of type "Wikimedia\Rdbms\DBQueryError".

This tool doesn't do what I thought it did/what the name implies: it ran UserRightsBot (which I took over a while ago) and some sort of image hashing bot that calls https://eatchabot.toolforge.org/image_hash/api?url=($URL) but doesn't seem to have any functionality. There is a "video" directory, but it only contains a venv. I have therefore disabled both cron jobs without replacement.

All done, seems to be working.

All done and seems to be working.

LGTM.

This should be all set now, but leaving this open for verification.

Acknowledging that this is happening. I will have the time to migrate in the next month or so, but probably not before the 14th.

Acknowledging that this exists. I will have the time to migrate in the next month or so, but probably not before the 14th.

This is actually NOT done completely, the category removal job still needs to be migrated. I will likely have time to get around to it in the next month or so.

I have (belatedly) fulfilled the edit request.

Yikes! Thanks for catching this. I'll probably be able to implement some sort of fix in a few days.

Looks to be fixed now, thanks!

@Stang I'm fairly new to phab, what does "stalled" mean and what needs to happen for something to be un-stalled?

Noting here that Euku responded to you at :w:de:Benutzer Diskussion:Euku#phab:T343573 (permalink).

This should be a link to https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Wikifunctions/User_rights (defined by the wikilambda-users-help-link message (live)), with the label from the wikilambda-special-edit-function-definition-special-permission-link-label message (live). The wikilambda-special-edit-function-definition-description message (live) also appears relevant.

This should be a link to https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Wikifunctions/User_rights (defined by the wikilambda-users-help-link message (live)), with the label from the wikilambda-special-edit-function-definition-special-permission-link-label message (live). The wikilambda-special-edit-function-definition-description message (live) also appears relevant.

externallinks:
Are we talking about (template|module)-generated links, or user-generated links? If the former, which templates are causing them?

Duplicate of T342794 (sorry!)

I tend to think this is not desirable, as large language models can spit out valid-looking answers that do not perform the requested operation. If this is implemented, there should be a big red warning requiring the user to confirm that they have reviewed the code and it functions as desired, perhaps also requiring testcases to be specified.

I'm getting "An error has occurred while searching: We could not complete your search due to a temporary problem. Please try again later.", which I assume is related.

Thank you very much! I've sent the required notices/emails. I'll (probably) be back in another 14 days to request adoptions.

Oh, OK. Thank you.

This is still an issue on Commons. To help understand impact: it's not just a js error in production, but it also prevents my port of Twinkle from working on filepages on Commons. See also T321532.

This is still an issue on Commons. To help understand impact: it's not just a js error in production, but it also prevents my port of Twinkle from working on filepages on Commons. See also T332305.

Never mind, just checked for duplicates that didn't come up in Google and found T321532, T332305, T213885#8567082. Probably should've done that first... :)

Thanks for the reminder email. Marked for deletion, see toolsadmin. Feel free to mark this as resolved if marking it for deletion is enough, otherwise I'll be back in 40 days. :)

I agree with Proc. This capability should be added, and communities and external projects should weigh the pros and cons themselves.

PR filed, see https://github.com/x-tools/xtools/pull/365.

PR filed, see https://github.com/x-tools/xtools/pull/364.

Actually, never mind. Withdrawn.

For ruwiki, the change was implemented with a !vote of 20 to 5 (80.0%). Here, the !vote was 20 to 6 (76.9%). I think that that 1-!vote difference is not material (disclosure: I was with the majority here).

Actually, does this need an update? NewPagesFeed_Templates.xml is an export of enwiki's templates (that I can't figure out how to easily generate), and modules/ext.pageTriage.defaultDeletionTagsOptions/ext.pageTriage.defaultDeletionTagsOptions.js is based off of that. If we want to change the names, we should probably also export the tags again. Would it make more sense to just update https://en.wikipedia.org/wiki/MediaWiki:PageTriageExternalDeletionTagsOptions.js instead (I believe this would have to be done anyways)?

That's odd: otrs-wiki is affected, but it doesn't use global accounts/centralauth...

Likely due to T255179.

Same on enwiki and commonswiki for me, Chrome and Firefox, continues with cookies cleared.

@Cyberpower678 What steps could I assist with to get this done?

@Aklapper I'd be happy to work on this, but have no experience with programming/deploying this bot. What steps could I help with?

What's the status on this? Having the ability to summon InternetArchiveBot would be extremely useful for licence checking.