You may need to set the user_touched field of the user table to the current timestamp (in case it's null or empty on the database, or if it has a future date). Check also the system clock (both from the database server and the application server) and be sure they're in sync

Yes - the environment is a Mediawiki 1.27.3 farm that is fully functional for half a dozen other wikis. Due to the farm aspect it won't be easy to switch off the extensions and we might have to retry the whole problem on a compatible other backup server where backups of the wikis run and the switching off will not harm production operations.

For the user table see the select below.

User 2 and 4 can't log in. For the others i do not have credentials but could try the maintainance/changePassword.php

select user_id,user_touched from user;
+---------+----------------+
| user_id | user_touched   |
+---------+----------------+
|       1 | 20160103160331 |
|       2 |                |
|       3 |                |
|       4 |                |
|       5 |                |
|       6 |                |
|       7 |                |
|       8 |                |
|       9 |                |
|      10 |                |
|      11 |                |
|      13 | 20160107082548 |
|      14 | 20160118204440 |
|      15 |                |
|      16 | 20160309172416 |
|      17 | 20170704143342 |
+---------+----------------+
16 rows in set (0.00 sec)

user_touched is a binary - how is this properly set with sql?

//I'm afraid there won't be documentation which covers each and every potential case why an error might be triggered by random code in a random extension.

I doubt an extension is the cause of the problem. For me it's more relevant that is a showstopper. Usually i love Mediawiki for being a software that will keep working even if part of the system or part of the pages are corrupted. Not being able to login is one of the rare cases that need a different approach. My hope would be that error messages from the "showstopper" category would be handled somewhere with an FAQ - a list of remedies or the like. The current Phabricator approach makes sifting thru the potential cases very hard. Also more often than not error messages are simply misleading.

Here are some of the hints i found:

• https://phabricator.wikimedia.org/T222195
• https://www.mediawiki.org/wiki/Topic:Tlfv7wmapqme4mj0
• https://phabricator.wikimedia.org/T95839
• https://phabricator.wikimedia.org/T150373
• https://www.mediawiki.org/wiki/Topic:Tlfv4v33bakto7e9

@Ciencia_Al_Poder

update user set user_touched='20200316120000' where user_id='2';

worked like a charm - this workaround should IMHO be promoted more prominently ...

update user set user_touched='20200316120000' where hex(user_touched)='0000000000000000000000000000';

is a more general approach

this workaround should IMHO be promoted more prominently ...

Please feel very welcome to add an item to https://www.mediawiki.org/wiki/Manual:Errors_and_symptoms !
Glad you found a workaround (and thanks @Ciencia_Al_Poder)!

Note: This page has been protected so that only autoconfirmed users can edit it. The latest log entry is provided below for reference:

I've removed the protection

Thx - i have added two issues see https://www.mediawiki.org/w/index.php?title=Manual%3AErrors_and_symptoms&type=revision&diff=3713734&oldid=3713641

Did you fiddle with the database to get those blanks there?

Not that I'd know of. All i did was dumping / restoring the database with mysldump and mysql command line