Change #1112335 had a related patch set uploaded (by Majavah; author: Majavah):

[operations/mediawiki-config@master] wikitech: Drop oathauth group

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

@Christian1985 please reopen if you still see it.

@Christian1985 sorry for the delay. @Krinkle could you have a look at the patch again. I find this regression gives a really bad impression as \limits is printed on the page.

After:

Change #1112334 had a related patch set uploaded (by Dylsss; author: Dylsss):

[mediawiki/extensions/UploadWizard@master] Remove fallback to Special:Upload and redirect user to alternative form

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

Change #1112334 had a related patch set uploaded (by Dylsss; author: Dylsss):

[mediawiki/extensions/UploadWizard@master] Remove fallback to Special:Upload and redirect user to alternative form

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

I think it would sense here to just redirect the user away in the rare case someone has JavaScript disabled. We can redirect them to Commons:Upload, where they can choose the relevant upload form, which I think is better UX especially since users using the UploadWizard are less likely to be experienced users. And it lets us get rid of bootstrapping Special:Upload which feels kinda hacky.

Change #1112333 had a related patch set uploaded (by Majavah; author: Majavah):

[operations/mediawiki-config@master] wikitech: Drop obsolete oauthadmin group

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

Thanks!

Yes, static calls. I instrumented it again, just before Save, and Barack Obama had used 50 cache slots. Without genfixes it uses 11 (I have a list if you want). Some will only be used during startup. Of course, modules and plugins are responsible for their own.

Ah no, they need to contact ca@. Okay.

In T383718#10473022, @KStoller-WMF wrote:

Thanks, @Urbanecm_WMF, for providing the details and organization to help facilitate this decision-making!

Closing since there's no open subtasks.

I disagree. The top notices aren’t difficult to fix:

Not saying this is the best strategy, but adding something like error_reporting(E_ALL & ~E_NOTICE & ~E_WARNING); (to not log notices and warnings) in php entrypoint should help.

In T381642#10473776, @RJ2904 wrote:

I want to work on this issue. Can you provide me with its github link?

Change #1112330 had a related patch set uploaded (by Majavah; author: Majavah):

[labs/striker@master] templates: Use Codex for tool project/repo pages

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

Thanks \o/

My bad, you're right about no-cache, sorry about that

weekly update: I started mapping out potential conferences and goals in this document

I’ve started the service again, and so far it seems to be up. If it’s normal for the tool to receive a lot of traffic, maybe it would make sense to run it with multiple replicas? (AFAICT --replicas=6 would easily fit within the tool’s current quota and still allow a rolling restart.) But it’s probably better for the tool maintainers to know that call. (I don’t know if the tool has any business logic that would be broken by having multiple copies of it running in parallel.)

Insufficient info to help in any meaningful way.

Change #1112323 merged by jenkins-bot:

[labs/striker@master] templates: Fix tool repositories not appearing

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

Mentioned in SAL (#wikimedia-cloud) [2025-01-18T12:16:40Z] <wmbot~lucaswerkmeister@tools-bastion-13> webservice php7.4 start # T384092

I want to work on this issue. Can you provide me with its github link?

weekly update:

weekly update: no major update this week

Many thanks for your reply.

MS documentation: https://learn.microsoft.com/en-us/dotnet/api/system.text.regularexpressions.regex.cachesize?view=netframework-4.5
That says "The Regex class maintains an internal cache of compiled regular expressions used in static Regex method calls"

is this still open?

Week 6 (Jan 13th - Jan 17th)
Tasks Completed:

Sadly, that stashed file expired. My latest one is https://commons.wikimedia.org/wiki/Special:UploadStash/file/1bidacse1o08.3e3cuf.122116.

Week 5 (Jan 6th - Jan 10th)
Tasks Completed:

https://archive.org/details/A253315
https://archive.org/download/A253315/A253315.pdf59.3M
chunk_size = 1024 * 1024

Hi Security Team,

I'm tempted to recreate the cluster, but maybe that wouldn't fix whatever the underlying issue is, and want to get some thoughts before I delete the current cluster and lose any of its logs/state which may be of value in debugging.

Change #1112311 merged by jenkins-bot:

[mediawiki/extensions/UploadWizard@master] Fix method calls by referencing fieldWidget

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

The libvert error seems to be fixed by T383583

Are you sure about no-cache being a response header only? Mozilla's HTTP docs suggest it can be used on a request or response, as do other resources such as RFC7234. I figured it was worth a try, even if Wikipedia's server's don't support/honour it.

Note: might be related to T383508