Do we bundle such notifications?

If we send them individually, I think we should consider including the whole thing (or setting the limit very high so it will only be hit by pathological cases).

I found the snippet code, but it doesn't mention why the truncation is done.

These usertalkpage messages are not bundled.
I don't think these are even part of Echo, are they? They're the years-old https://www.mediawiki.org/wiki/Manual:$wgEnotifUserTalk

I'm asking some people if they know/recall why the limit is set so low...

In T64661#971699, @Quiddity wrote:

These usertalkpage messages are not bundled.

We've had some back and forth on this point, so we need to figure it out definitively as part of this change.

I don't think these are even part of Echo, are they? They're the years-old https://www.mediawiki.org/wiki/Manual:$wgEnotifUserTalk

No, this is now managed by Echo (if installed, of course) for consistency. See https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FEcho.git/4db0c7ca94d9bee6ac1d69c7ddf7a3f57d38da80/Hooks.php#L328 .

Also, this is why these emails use the Echo styling:

I'm asking some people if they know/recall why the limit is set so low...

I believe the team consensus at the triage meeting was that it should be fine to raise it, but if you find a reason, it would be important to know, of course.

In T64661#971699, @Quiddity wrote:

I'm asking some people if they know/recall why the limit is set so low...

ebernhardson said it might have been since that truncated version is also used in a flyout (but there is no inherent reason the limit has to be the same for both)

This is a regression, because MediaWiki core (enotiftalk/enotifwatchlist) does better.

Also reported by Ckoerner.

Is T90474: Echo email notifications should not truncate text a dupe of this?

I help manage the MediaWiki social media accounts. Another log on the pile for this feature request:

https://twitter.com/owenblacker/status/843877613336743937

That screenshot shows that Echo is still not showing the edit summary and therefore worsens the notifications compared to the traditional enotiftalk/enotifwatchlist email notifications of MediaWiki core.

I'm the Twitter user in question — the problem I'm complaining about is that User:MediaWiki message delivery fails to provide an excerpt. That might be because there's a bunch of divs confusing matters, but it's only ever those messages that fail to get any useful detail in the Echo email.

I believe T59152: Echo: talkpage messages without a 4-tilde signature do not generate correct section links or summary is the culprit for that. I've added another note there.

I accidentally asked this in the wrong task:

In T335535#11386727, @Ladsgroup wrote:

In T335535#11380421, @Tgr wrote:

There are three lengths:

• how much goes into the database
• how much goes into the email
• how much goes into the flyout

We probably don't want to put a lot of text in the flyout. But (IMO) we do want to put a lot of text in the email, something like 30K should comfortably fit into the DB.

@Ladsgroup do you think there are DB size concerns here? At the very worst this would duplicate how much DB space is taken up by user talk pages, right? (Or talk pages in general if we extend the concept to notification emails about other kinds of messages.)

Content of user talk pages are stored in ExternalStore which has a completely different architecture and is designed to handle large blobs of text. x1/core dbs are not designed for this.

Several mitigations I can think of:

• Compress the text via gzip before store and retrieval, see what we did for cx_corpora: T351911: Compress cx_corpora.cxc_content
• And put a limit somewhere, 2KB, etc. It's not about really how much the storage can take, it's about putting a limit (and avoiding waste) and then if the user is really interested, they can simply click on the link.
• And put a time limit on notifications and simply start dropping really old ones: T383948: Echo notification expiration should be time-based, not hardcoded 2000 -We can also flip it and basically delete any notification for users who haven't logged in for X time (similar to user_props T406724: Clean up watchlist and user properties of users if they don't log in for certain time)

Also I wonder if we really need the DB here. Can we just put the revision ID in the event, and parse the revision on the fly? In general maybe there would be performance concerns (although all notifications about the same event are sent out roughly the same time so caching should work well), but specifically for talk pages, there's only one notification per event.

That would be nicer indeed.