Change 912952 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/Flow@master] Notifications: Allow configuring the truncation length of content

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

Duplicate of T64661: Echo: Emailed Notifications for new usertalkpage messages should include more or all of the message I think?

Change 912952 merged by jenkins-bot:

[mediawiki/extensions/Flow@master] Notifications: Allow configuring the truncation length of content

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

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.)

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.

This task is specific to StructuredDiscussons which is being undeployed soon. Are you sure you're in the right place?

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.

In T335535#11380624, @Pppery wrote:

This task is specific to StructuredDiscussons which is being undeployed soon. Are you sure you're in the right place?

Uh, right. There is no other task though (aside from the parent) so let's just make this one more generic.

On second thought, let's not, I'll just copy the DB comment to a better place.