I guess so… I kinda forgot that there was a plausible fix for this :D (I wasn’t very convinced by the “concurrent refresh” theory, because it didn’t seem to match how the users told me they were using the tool, but I guess after three months with no more issues it’s good enough.)

(FTR, @TheDJ already uploaded a patch for this before I created the task.)

+1 – as I wrote in #wikimedia-cloud yesterday, I don’t find components a very relevant “entrypoint” given that most of my tools don’t have multiple components.

There's an underlying security issue of trusting the deploy request with passing the configuration. As someone that is able to get the deploy token will be able to change the configuration at will (as opposed to currently, where they will only be able to trigger a deployment, that will pull the config from the already setup and trusted repo).

I finally thought of a better way to work around this: port-forward MariaDB through SSH and then run mariadb-dump locally (after also threading the replica.my.cnf file through SSH so the local mariadb-dump can see it). https://github.com/lucaswerkmeister/home/commit/2593334c27

Something seems to be broken again – Wikidata Lexeme Forms has a twn branch with a commit from 20 August, but no corresponding merge request.

In T420833#12241539, @jeremyb wrote:

how important can an automation be if no one noticed it stopped working?

For search purposes: in the console this looks like

In T420833#12239970, @Hakimi97 wrote:

I asked ChatGPT 5.6 Sol Extra High

Given T401993: [components-api] Add a "description" field to the deployment, this should probably be built on top of that – the CI pipeline submits an automatic description based on the commit message (or range) with the deployment (and an “enable SAL” flag, e.g. based on an envvar?), and the components API then logs that description (if enabled).

Can confirm it’s working now \o/

(Still no trace of the error in the logs… I’m starting to think I should port more tools to OAuth 2 + mwoauth2, despite this bug, just so it’ll recur sooner. Though that means I also have to include the debug code everywhere.)

Thanks! \o/

This was done some time ago in the context of another task.

IMHO we can call this resolved now, they’ve started adding versions again – currently Codex 2.5.1 is available on cdnjs. (2.6.0 and 2.6.2 aren’t, but I’m guessing they’ll add those eventually. codex-design-tokens and codex-icons both have 2.6.2 available. Note also that the cdnjs-index page on Toolforge is incomplete due to T431039.) Feel free to reopen if you disagree.

Also per Taavi, “Checking your browser” (Cloudflare, I think?) also seems like a good title to blocklist.

Pointed out by Taavi: apparently @Mvolz already got us on Anubis’ good bots list, so this is mainly an issue with older Anubis installations (if I understand correctly).

In T432838#12213313, @abi_ wrote:

Unable to create a pull request for cite-unseen: Environment variable L10NBOT_TOKEN_gitlab_wikimedia_org is not defined

(And, before the rethrow, remove the now-invalid access and refresh tokens from the session. And then it’s up to the user to catch the error and handle it by logging in again. Right?)

I just tried it out (by revoking the m3api-examples client at Special:OAuthManageMyGrants), and the result with current m3api-oauth2 is:

Edit: disregard, belongs in T431363.

I think there might still be a problem – the twn branch was just updated (Thu Jul 23 14:30:58 2026 +0200) but there’s still no merge request.

Can confirm it works again, thank you!

I see, thanks! (I just noticed that Wikidata Image Positions has the same issue, but you also mentioned that in the comment over there.)

Looks like it, checking out that commit makes CI pass. Thanks!

Yes, that’s correct :) we just got sidetracked for a bit. (And also, T431631 will improve the way this bugfix is implemented.)

In T431363#12102550, @LucasWerkmeister wrote:

Well, given that refresh might transparently happen in the background at any time, I think you need to serialize the session at the end of each request anyway? (Or at least check if the new serialization is different from what’s currently stored, if you want to avoid triggering some “the session was touched, persist it now” mechanism of your web framework.) Though the current webapp examples don’t do this 🤔 I should check if that’s a real bug…

Yup, confirmed.

As I wrote in the GitHub issue:

the “save session at the end of each request” approach

Well, given that refresh might transparently happen in the background at any time, I think you need to serialize the session at the end of each request anyway? (Or at least check if the new serialization is different from what’s currently stored, if you want to avoid triggering some “the session was touched, persist it now” mechanism of your web framework.) Though the current webapp examples don’t do this 🤔 I should check if that’s a real bug…

In T431363#12101541, @Gouvernathor wrote:

I think you need to serialize the session at the end of each request anyway?

Well, I don't think that's great, and with my idea of passing a callback in the options, you wouldn't have to.

That’s a fair point. The docs for isCompleteOAuthSession() obliquely refer to a similar situation –

If you don't want to break anything, and you want to start using "exports", then you need to list all the files that are currently accessible each as a separate import.

I’ve already made the decision, which is to not make any breaking changes to the imports at this time. But it sounds like it’s also possible to improve the situation for TypeScript without breaking anything else, so my questions at the moment are:

(It might take a while for the error to show up again – the two reports I received about it so far were on 31 May and 3 July, so a bit over a month apart. Feel free to forget about this task in the meantime, and I’ll shout here when there’s something new to inspect ^^)

In T431146#12087378, @Tgr wrote:

A request ID would be a good start.

(The only other Phabricator task with this error message is T268256, which was closed with no action after the error seemed to resolve itself. :/)

Tagging this with MediaWiki-extensions-OAuth in the hope that someone knows what might be going on or how it could be debugged.

I suppose an alternative solution would be to fetch the URLs for alternative solutions on demand as the user clicks that library version. In principle we could even do that in the browser – the CDNjs API is CORS-enabled – but that’s probably going to be blocked via CSP at some point (and also, not leaking IPs to Cloudflare is kind of the whole point of our CDNjs mirror, and it would be nice to extend the same courtesy to the developers using the Toolforge CDNjs front page). So that would require setting up a proper webservice, rather than just serving the static index.html.

I’ll be honest, I’m very much inclined to agree with Past Lucas right now:

In T430738#12073399, @LucasWerkmeister wrote:

Also, there is apparently a workaround (h/t nyanbinary on fedi), which is to make your own Request to robots.txt (with a better user agent) and feed that into rp.parse().

I’m not sure which tags to add to this (is it SRE territory?); CC @Krinkle who made the last few commits to w/robots.php.

So the pull request I put forwards uses "exports" to make it so that in Node, importing the package imports the node version, and otherwise, the browser version. And with typing associated with it as well.

The constraint is declared on property P31 following the same pattern as other type-related constraints (TypeChecker, ValueTypeChecker, SymmetricChecker)

FYI: I’m not sure if it qualifies as a train blocker, but T428649: [regression] Duplicate p-tb (tools/toolbox) menu in Vector 2022 caused by watchstar/bookmark icon changes looks to me like a regression in this week’s train.

(Boring additional context: this breaks the browser tests of the AC/DC gadget, because opening the “tools” menu is no longer sufficient to make the portlet link visible. I initially wasn’t sure if this was a bug or an intentional change, but noticing that there are two elements with id="p-tb" on the page convinced me that it’s probably not intentional.)

It’s working again, thanks \o/

Yes, e.g. Josh404Bot has the fourth-most batches on QuickStatements:

In T421631#11889934, @Ifrahkhanyaree_WMDE wrote:

You'd want the REST API to check on the server side whether a user has bot permissions or not, and if they do not they'd get an error (?)

(The task title and/or description could probably still do with some refining. Arguably the user agent part is covered by T422686; but beyond that, I think site operators need the ability to send authorized requests so they get higher rate limits, and that’s what the second and third patch attached above try to do.)

The above three patches are currently deployed on FactGrid, though it’s unclear how much they help. (The first one alone had no effect other than changing the error message a bit, see discussion; I haven’t yet heard back from the wiki editors about the other two changes.) They’re probably not ready for merging as-is, but more of a starting point. (But it would be nice to get something merged and backported soon, given that the rate limit rollout continues unabated.)

Alright, replied something along those lines. Thanks.

Hello
I have a small favor to ask. I am currently focused on building my professional network. Would you or a member of the team be willing to leave a quick 2-sentence recommendation on my LinkedIn profile instead of (or in addition to) the listing?

A brief note about my help to you .

You can leave it directly on my profile here: www.linkedin.com/in/zohair-laaraich-a940a23ab

Thanks again

Best regards,

See also: P90329, P91514 (the first one isn’t very closely related but the second one is a hard requirement of this change for introducing $wgSiteAccessTokens in the first place).

I think this could be a Wikimedia-Hackathon-2026 project, by the way? I don’t know how far we’ll get on the CDN side, but the MediaWiki side should be relatively doable (use request_parse_body() if available, else parse_str() as Daniel mentioned).

See also: P90329, P91524

See also: P91514, P91524

Thank you!

In T423940#11846441, @LucasWerkmeister wrote:

Probably nothing else to do here

Thanks for your reply.
aI understand your situation.
Add me as the name ZOHAIR LAARAICH.

Thanks again .
Best regards