• Seems EchoEventPresentationModel.php $user->isRegistered() returns false for external (Wikibase) account. This account The monster is my thing ill do this if im thing is not registered on wikimaniawiki (and won't be).
• The agent name is truncated resulting in _ at the end which is invalid Title.

More context:

• It's trying to show a notification about this edit: https://www.wikidata.org/w/index.php?title=Q1138776&diff=prev&oldid=2173575677 which added a pagelink to wikimaniawiki page "2024:Venue"
• The username The_monster_is_my_thing_ill_do_this_if_im_thing is truncated to The_monster_is_my_thing_ill_do_this_if_, which is 39 characters, a very unusual length. I searched Echo code for that number and found that event_agent_ip field is 39 bytes: https://gerrit.wikimedia.org/g/mediawiki/extensions/Echo/+/2a4e100a322fe5a28ad54883d47d2daa0f954765/sql/mysql/tables-generated.sql#10

So it seems that the account was treated as unregistered when creating the notification, and now there's bad data in the database.

This is probably a Wikidata-specific issue, caused by creating cross-wiki notifications when the user account only exists on one wiki.

• This code needs to be updated somehow (not sure how) to handle this case: https://gerrit.wikimedia.org/g/mediawiki/extensions/Wikibase/+/45b17ac506c70550b2f78393deda7c1882b9fa22/client/includes/Hooks/EchoNotificationsHandlers.php#198
• And this needs to be updated to handle the invalid entries already existing in the database, without throwing an exception: https://gerrit.wikimedia.org/g/mediawiki/extensions/Wikibase/+/45b17ac506c70550b2f78393deda7c1882b9fa22/client/includes/Notifications/PageConnectionPresentationModel.php

@tarlocesilion Until this is fixed, I think you can regain access to your notifications by going to https://wikimania.wikimedia.org/wiki/Special:Preferences#mw-prefsection-echo and unchecking "Connection with Wikidata" (assuming you don't need this type of notifications).

In T367638#9896494, @matmarex wrote:

So it seems that the account was treated as unregistered when creating the notification, and now there's bad data in the database.

Yes. Should isRegistered return true for global accounts (even no local created)? This needs to be checked also in light of forthcoming temporary accounts.

This is probably a Wikidata-specific issue, caused by creating cross-wiki notifications when the user account only exists on one wiki.

Note there are currently at least two cross-wiki kind of notifications. There is also possibility to view notifications from all wikis on one wiki (by default). This issue needs to be tested also with this.

• And this needs to be updated to handle the invalid entries already existing in the database, without throwing an exception: https://gerrit.wikimedia.org/g/mediawiki/extensions/Wikibase/+/45b17ac506c70550b2f78393deda7c1882b9fa22/client/includes/Notifications/PageConnectionPresentationModel.php

The exception is good. There may be other unforeseen problems in future that will need to be detected this way. Non-ips should not be treated internally as IPs. Database entries needs to be fixed after fixing the code. But I agree this should not blocking whole notifications page. Maybe ignoring suspicious items?

Prio Notes:

It seems two problems meet here:

• On the Wikibase side (in fact, it's me to blame), no assumption is made about whether the user exists locally. Maybe I was too lazy to test it ("It could be an IP, anyway").
• On the Echo side, it is assumed the agent is either registered (exists locally) or an IP address.

I'm wondering how this "timed bomb" could go unnoticed for so long. Maybe such lengthy usernames are unusual (note that this one is an LTA) and their users are even less likely to connect pages to Wikidata. Maybe something in the "autocreate when the change is propagated from Wikidata" mechanism changed and some assumptions are not valid anymore (race condition?). Maybe they have never been valid.

If we cannot assume the user exists locally, what should be done?

• Force local autocreation? (How difficult is it?)
• Insert the notification without an agent?
• Insert no notification?
• Fix Echo? Echo should definitely throw an exception if it cannot handle the user, but there would still be an error (prior to insertion, so no data corruption).

The status of temporary accounts should also be made clear (this is indeed a good opportunity).

39 characters, a very unusual length

IPv6, I guess (at most 32 bytes + 7 colons = 39).

In T367638#10022975, @matej_suchanek wrote:

If we cannot assume the user exists locally, what should be done?

Or some interwiki pointing. The action is done using account on external wiki, so that account should be linked anyway. To be handled by CentralAuth and their hooks?

In T367638#10023959, @Wargo wrote:

In T367638#10022975, @matej_suchanek wrote:

If we cannot assume the user exists locally, what should be done?

Or some interwiki pointing. The action is done using account on external wiki, so that account should be linked anyway. To be handled by CentralAuth and their hooks?

That's actually what Wikibase does when it inserts recent changes. (So I am striking what I wrote.) But there is still that one problem:

event_agent_ip field is 39 bytes

In T367638#10024027, @matej_suchanek wrote:

In T367638#10023959, @Wargo wrote:

In T367638#10022975, @matej_suchanek wrote:

If we cannot assume the user exists locally, what should be done?

Or some interwiki pointing. The action is done using account on external wiki, so that account should be linked anyway. To be handled by CentralAuth and their hooks?

That's actually what Wikibase does when it inserts recent changes. (So I am striking what I wrote.)

Yes, but not for Echo.

Striked part is for something else.

In T367638#10024027, @matej_suchanek wrote:

But there is still that one problem:

event_agent_ip field is 39 bytes

No, this is not problem. It is valid behavoiour.. As you pointed above, it is longest length of IP address. Extension assumed this account is IP because it doesn't exist - this is the real problem.

Change #1065754 had a related patch set uploaded (by Matěj Suchánek; author: Matěj Suchánek):

[mediawiki/extensions/Wikibase@master] Do not set the event agent if it doesn't exist locally

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

Change #1065876 had a related patch set uploaded (by Matěj Suchánek; author: Matěj Suchánek):

[mediawiki/extensions/Echo@master] Disallow anonymous non-IP agents, handle truncated names

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

moved back to task breakdown as current status of the ticket/ acceptance criteria is unclear

to do: review https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1065754, assign back to matej and then remove from wmde dev board

Change #1065754 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Do not set the event agent if it doesn't exist locally

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

Note that to prevent the fatals (original report), the other patch for Echo is also needed. But that may be out of scope for Wikibase people.

Change #1065876 merged by jenkins-bot:

[mediawiki/extensions/Echo@master] Disallow anonymous non-IP agents, handle truncated names

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

Anything left to do here?

In T367638#10332816, @Pppery wrote:

Anything left to do here?

I don't think so (on the technical level). I do not know what QA or communications is maybe planned from the Wikidata/WMDE side.

Bigger picture, I would really like for the database to fail loudly when one tries to insert a string that is too long, or filter by a number from a column that contains strings or something like that. But that is out of scope of this task.

Perhaps @tarlocesilion can tell if they can access all their notifications again.

Possible follow-ups:

• Watch for instances of ERROR in the Echo channel: https://grafana.wikimedia.org/d/000000102/mediawiki-production-logging
• Turn the new logging into an exception.
• T286153: Update `echo_event` table to reference core `actor` table (database cleanup)
• I would really like for the database to fail loudly when one tries to insert a string that is too long

I would really like for the database to fail loudly when one tries to insert a string that is too long

I believe T108255: Enable MariaDB/MySQL's Strict Mode would cover that.