We (DBAs) cannot really do much about it, if the write takes longer than 3 seconds, MW aborts it. Maybe Platform Engineering can help.
All our masters look fine at the moment.

I should have checked if it really failed or not, but if it did, why did it say {"globalpreferences":"success"}?

I'm thinking maybe this is a kind of edit conflict, my script changes two different preferences at practically the same time. I wouldn't expect an issue since it's not the same preference, but maybe it's an issue anyway.

On top of that, beta cluster has its own issues and might be related to many of its problem. It can be still reproducible in production but I haven't seen that.

In T311308#8026100, @AlexisJazz wrote:

I'm thinking maybe this is a kind of edit conflict, my script changes two different preferences at practically the same time. I wouldn't expect an issue since it's not the same preference, but maybe it's an issue anyway.

Point 1:
The preferences are handled as one. To change one preference all preferences of the userid are read from the database, the change is applied to that data and the according changes on the database are done with DELETE + INSERT. It seems the global preferences is using REPLACE + needed DELETE, not sure if that makes different on locking.

Point 2:
According to the Etiquete https://www.mediawiki.org/wiki/API:Etiquette avoid parallel requests, just combine both in one query to improve performance

In T311308#8113569, @Umherirrender wrote:

In T311308#8026100, @AlexisJazz wrote:

I'm thinking maybe this is a kind of edit conflict, my script changes two different preferences at practically the same time. I wouldn't expect an issue since it's not the same preference, but maybe it's an issue anyway.

Point 1:
The preferences are handled as one. To change one preference all preferences of the userid are read from the database, the change is applied to that data and the according changes on the database are done with DELETE + INSERT. It seems the global preferences is using REPLACE + needed DELETE, not sure if that makes different on locking.

Point 2:
According to the Etiquete https://www.mediawiki.org/wiki/API:Etiquette avoid parallel requests, just combine both in one query to improve performance

That's not always an option. (though I try to do that more now) If one preference needs to be updated and you know that MAYBE further down the code you'll change another, what would you do? You don't know yet if you'll be going down that path.

When the user marks individual notifications as read in quick succession within my script (and these notifications are stored as a preference), what am I supposed to do? Can't predict if the human is going to click another thing.

I'm now trying to queue these things which introduces its own problems. Edit: I think that's working now.

Besides, when the user enables/disables https://www.mediawiki.org/wiki/Extension:CodeEditor or https://www.mediawiki.org/wiki/Extension:CodeMirror a preference is updated beyond my control.

Until we see an error in production, I think it's safe to assume this probably isn't an issue with GlobalPreferences, specifically. Please correct me and/or re-tag if anyone feels otherwise!