Wed, Sep 20
Tue, Sep 19
Mon, Sep 18
During request shutdown, zend_objects_store_call_destructors() calls destructors in ascending order of object ID. It doesn't attempt to follow the reference tree. So it's unsafe to do anything complex or non-local at this stage, since indeed, destructors of properties may be called before the destructor of the parent object.
Thu, Sep 14
Wed, Sep 13
Fri, Sep 8
Thu, Sep 7
Wed, Sep 6
ext.phonos depends on oojs-ui-widgets but it could apparently depend on oojs-ui-core instead.
I've deployed the fix on wmf.25 so the error should go away once this week's train deployment is complete.
Tue, Sep 5
Mon, Sep 4
If someone goes to the login form and enters the name of a temporary user and an incorrect password, there's no need to notify the temporary user because there is no risk of account compromise, because temporary users never have a password. Currently, a notification will be sent.
There is migratePreferences.php but it is just updating preferences that already exist in the DB. It would not be correct to skip temporary users in that situation.
Fri, Sep 1
I could not reproduce the actual browser limitations this is supposed to work around, just tested that the top-level autologin works. Typically 3rd-party browser limitations are only triggered by requests across different second-level domains, so I figured it will be easier to test that in production.
Logstash only shows 5 errors in the past 24 hours, so I am assuming that it is fixed rather than confirming.
The fix is actually already out. Despite the release notes tag, it went out with wmf.24.
The core documentation issue was fixed in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/954121 . The incorrect doc comment also exists in CheckUser so I will fix it there too.
User::newFromName() casts the name to a string. I changed it to use UserFactory in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/LoginNotify/+/952114 but UserFactory::newFromName() throws an exception instead of casting.
Thu, Aug 31
Some users will notice when this goes out with the train, so we should probably put out an explanation.
You could lsn_id make BIGINT to avoid having headaches in the future.
Wed, Aug 30
I believe it was @Prtksxna who expressed the concern that consecutive numbers, with most of the digits being the same between users created at a similar time, would be too hard for reviewers to distinguish in a changes list. I suggested a pseudo-random sequence as a way of making the numbers be easier to visually distinguish.
Tue, Aug 29
After reading https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.html I decided to add an auto-incremented primary key, instead of a time index. If you leave off the integer primary key, the secondary index needs to duplicate the 14-byte unique key, so it actually uses more space overall. Purging can be done using the primary key, if you assume it's monotonic in time.
Community Tech are looking at this, following its high ranking in the 2023 Community Wishlist Survey.
Mon, Aug 28
There is also T240664 for LuaSandbox which fails with the same error.
This was fixed as part of T233004.
Fri, Aug 25
|Setting||Old value||k8s value||Notes|
|apc.shm_size||6096M||768M||Hopefully there's some sort of plan for detecting whether this is enough.|
|max_execution_time||210||180||Wrong, must be 210 so that RequestTimeout can kill the request and show a pretty error message. RequestTimeout for POST requests has a limit of 200 seconds so 210 gives a 10 second grace period.|
|memory_limit||500M||200M||Don't know how this is expected to work|
|opcache.max_accelerated_files||24000||32531||How was this value derived?|
|opcache.max_wasted_percentage||10||unspecified (default 5)|
|pcre.backtrack_limit||5000000||50000||We need our zeroes back|
It's been this way since 2020?
$ sudo mw-debug-repl -e enwiki Finding a mw-debug pod in eqiad... Now running eval.php for enwiki inside pod/mw-debug.eqiad.pinkunicorn-6bcc7484cf-6jmbw... > print ini_get('pcre.backtrack_limit'); 50000
Note that the error was thrown from a Kubernetes pod. We should confirm that php.ini is correct in Kubernetes. On bare metal hosts, it is set to 5000000.
Most likely opcache corruption. Errors started only 1ms after the request timeout at 12:36:03.013, and then there was a flood of segfaults over the next few hundred milliseconds, finishing with "[WARNING] failed processes threshold (40 in 60 sec) is reached, initiating reload" at 12:36:03.800.
Thu, Aug 24
Aug 24 2023
Aug 23 2023
We used to use TMH to play audio in Score, but I got rid of it in cf8a4f2133cb6a0f9fa4266ed93acea4f0729667 and just used <audio> instead, because TMH was too tightly integrated with file uploads to reliably play a thing that wasn't an uploaded file, and its audio support was very poor.
Although, come to think of it, it's a somewhat implausible story, since you would think <img alt=""> would do the job well enough. It's possible the logo div was a hack for some other non-CSS client and I'm confusing it with Monobook's screen reader hacks.
Aug 22 2023
Aug 21 2023
When I tested this locally using GlobalBlocking, I found that auto-creation actually succeeds. The IP address is globally blocked, but that is not actually checked for in CheckBlocksSecondaryAuthenticationProvider. There's a comment which says it is the responsibility of authorizeCreateAccount(), but that is not called.
Aug 18 2023
I can't reproduce it anyway, because I don't know how you load a user script from meta in a way that would trigger this error. I tried checking Northern Moonlight's user scripts, but there was nothing helpful there. Most user common.js pages just use importScript() or importScriptURI(), neither of which use mw.loader.impl() as far as I can tell.
Although it looks like everything is on wmf.22 now, so too late. It should be fixed already.
Sorry, I thought we wouldn't need that cherry pick because the rest of the branch wasn't merged yet -- didn't look closely enough. I will deploy it now.
- Set up CentralAuth with two pilot wikis and one non-pilot wiki with reservedPattern as described above.
- Set up $wgForeignUploadTargets and use it to perform a foreign upload as a new normal user.
Aug 17 2023
Ideally tests should be done with various combinations of the wikis being in the same and different cookie domains. But I don't really want to add more wikis to my CentralAuth farm if I can help it, since there's not much automation. It's easier to repeat the tests with different $wgAutoCreateTempUser configurations. I have four wikis, which are analogous to loginwiki, enwiki, frwiki and enwikiquote.
- On non-pilot wikis, the temp user prefix will be reserved with $wgAutoCreateTempUser['reservedPattern'], so it will not be possible to manually create a local account which has the same name as a global temp user. This seems prudent and was a design assumption for T307064 which introduced reservedPattern.
- Make UserNameUtils::isUsable() return false if isTempReserved() is true but isTemp() is false. So temp user reservations will be analogous to $wgReservedUsernames.
- Thus CentralAuthSessionProvider and CentralAuthTokenSessionProvider will reject the global session due to isUsable() returning false.
- In AuthManager::autoCreateUser(), where it says that we switched from isCreatable() to isValid() to support temp users, this will be changed again to instead call isUsable(). So auto-creation will be denied for foreign temp users on non-pilot wikis when it is requested by Special:CentralAutoLogin, ApiCreateLocalAccount, etc.
Aug 16 2023
Aug 15 2023
I'm working on a commit that avoids doing purges when the cache is empty.
This feature is called the hold-off period, and it is discussed in a few places in the source. There is likely some production impact. For 11 seconds after a purge, every request is a miss. OK, reasons are given for this. But also for 11 seconds following regeneration due to an empty cache, every request is a miss except in the first 50-100ms after each regeneration. This does not seem to be justified. It dates back to 2015 a0cce5e4b63d9607f4561298d346695bd4d1c31c. This detail was not discussed in Gerrit.