In theory, this would open us up to a DoS attack, where someone could trigger thousands of notifications in a minute, flooding the storage. However, creating eg. a revision takes way more rows/space than a single notification, so this may not be a concern? Regardless, it is something that needs to be considered.

Echo's database is much healthier now and if users are asking for a higher value, I think we can bump it to 5K but there should be a limit somewhere both timestamp and number. Once the limit on timstamp is set, we can bump the number to a higher value but I don't think we can fully remove it

In T383948#10475921, @Urbanecm_WMF wrote:

In theory, this would open us up to a DoS attack, where someone could trigger thousands of notifications in a minute, flooding the storage. However, creating eg. a revision takes way more rows/space than a single notification, so this may not be a concern? Regardless, it is something that needs to be considered.

There should be some rate limits on this?

There aren't any rate limits on notifications themselves, but there are rate limits on the actions that cause a notification to be sent, like editing pages.

In T383948#10572588, @matmarex wrote:

There aren't any rate limits on notifications themselves, but there are rate limits on the actions that cause a notification to be sent, like editing pages.

Yes. That was my point. Thanks for clarifying.

Notes:

1. Proper versioning means being prepared to do "complex migrations" as in the example the description mentions. We should deal with our technical debt neither "just leaving mistakes in forever" nor deleting data to hide the past.
2. The original reason for imposing a limit has never been discussed with the community. The change https://www.mediawiki.org/w/index.php?title=Topic:S2gux2za46y9zqsv&topic_showPostId=v3aoduag8wpvgroy#flow-post-v3aoduag8wpvgroy was put live some 10 years ago to address a "production bottleneck". No engagement has occurred to discuss what the "production bottleneck" is or was. However it is quite possible that a simple change to a SQL query somewhere would have obviated the whole enterprise. We should look into this before replacing one deletion system with another, however superior. For example it may be possible that simply having an "archive" bit set for everything over 12 months would resolve the production bottleneck. It may be that the bottleneck is in code that has since been deleted, or that another change has rendered in no longer a bottleneck.

FWIW, I look at notification timestamps and their distribution over the years. In total we had 232M notifications recorded and this is their cumulative percentage:

Of course we can start with some ridiculous number (anything older than ten years) and then slowly reduce the years to something reasonable. Seems like 5 years is a good compromise of being long enough but also can clean up a decent chunk (around half!) of notifications. cc @matmarex

My opinion is that we should have both number limit and time limit but if we clean up old notifications (e.g. older than five years) then we can bump the 2,000 limit to something bigger.

@KStoller-WMF said she is okay with the following proposed change: Delete notifications older than 5 years (which will cut the size of the table to half)‌ and in return, increase the maximum number allowed for each user from 2,000 to 10,000.

From my perspective, I would be comfortable with this change, and it seems logically sound. Notifications are generally designed to be time bound rather than permanent records. On most platforms, users understand that notifications are not retained indefinitely and are instead intended to surface timely information.

If we can meaningfully increase the maximum notification limit in exchange for removing very old notifications, that could be a reasonable trade off. It balances system constraints with user expectations and aligns the feature more closely with how notifications function elsewhere.

That being said, I would love to hear from someone from Movement Communications about how we should loop in the community. @Quiddity - could we simply announce this ahead of time in Tech News? Or is some other communication needed here?

Change #1239793 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[mediawiki/extensions/Echo@master] Delete old notifications of users

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

Thanks!‌ I‌ made a quick patch that would drop the old rows in case a new notification is being inserted. It doesn't automatically clean up everything but it should clean up a lot. Before merge and deploy, definitely a tech news entry sounds good to me. I‌ leave it to Nick on how to proceed and/or whether a consultation is needed beforehand.

I would suggest writing a Tech News entry that gives a clear explanation of what is changing and why, plus gives a 2 week deadline for feedback in case there's something we've overlooked. E.g. Perhaps something like this? (Please expand and rewrite/improve however you can!):

• Notifications are currently limited to 2,000 historic entries per user, and extend back to 2013 when the feature was released. This is going to be changed in two weeks, to only store Notifications from the last 5 years, but up to 10,000 of them. This will help with long-term code maintenance and help to prevent more recent notifications from disappearing too soon. [plus any other important reasons to highlight?]. [1]

I cannot immediately think of any major concerns, but the edge-case that springs to mind is: For editors who are active long-term on multiple wikis, they might have Notifications on a sister project that they're intending to come back to, which are currently easily accessible. - E.g. If I go to Wiktionary, which I only edit occasionally, there's a 7 year old notification about a task-idea that I keep intending to get back to, and I don't have it written down because I know it's there at the top of my local Notifications... [This task is now prompting me to make a proper note-to-self about it.]

Sounds good to me!

Thanks for pushing this forward @Ladsgroup and @KStoller-WMF.

I think we should have at least two notifications in Tech News, given that we're about to permanently delete data:

• One notification well ahead of time, so that if some problems are raised in response, we could still change the plan
• Second notification just before the data starts being deleted

Also, I wish we could document a way to export your notifications before they're gone. I think the action=query&meta=notifications API would be an acceptable way to do this, were it not for the fact that it is limited to 50 notifications – could we temporarily increase this limit to 2000? (perhaps with a rate limit to avoid issues) [I can write the patch for this]

@Quiddity I think it's a good point that unread notifications could be exempt from the time limit, and only subject to the total count limit.

Eh, on second thought… handling unread notifications differently kind of defeats the point of the change. So, I wish we could do that, but I don't think it's practical to do. Anyway, that makes it all the more important to notify earlier :)

To finalise things, this is the final copy I am adding to Tech News:

"Notifications are currently limited to 2,000 historic entries per user, and extend back to 2013 when the feature was released. This is going to be changed in two weeks, to only store Notifications from the last 5 years, but up to 10,000 of them. This will help with long-term code maintenance and help to prevent more recent notifications from disappearing too soon."

Please ping me with corrections if any. In the meantime I will add the entry to the draft.

In T383948#11625283, @Quiddity wrote:

I would suggest writing a Tech News entry that gives a clear explanation of what is changing and why, plus gives a 2 week deadline for feedback in case there's something we've overlooked. E.g. Perhaps something like this? (Please expand and rewrite/improve however you can!):

• Notifications are currently limited to 2,000 historic entries per user, and extend back to 2013 when the feature was released. This is going to be changed in two weeks, to only store Notifications from the last 5 years, but up to 10,000 of them. This will help with long-term code maintenance and help to prevent more recent notifications from disappearing too soon. [plus any other important reasons to highlight?]. [1]

I cannot immediately think of any major concerns, but the edge-case that springs to mind is: For editors who are active long-term on multiple wikis, they might have Notifications on a sister project that they're intending to come back to, which are currently easily accessible. - E.g. If I go to Wiktionary, which I only edit occasionally, there's a 7 year old notification about a task-idea that I keep intending to get back to, and I don't have it written down because I know it's there at the top of my local Notifications... [This task is now prompting me to make a proper note-to-self about it.]

Instead of "long-term code maintenance" I'd say "long-term infrastructure health" otherwise looks great!

@Ladsgroup I have made the change however now, the announcement will need to to be more specific about when the users can expect the change. Also, this is a good link for this entry right https://www.mediawiki.org/wiki/Notifications? Please check the draft below to see if I have captured things well:

"Notifications are currently limited to 2,000 historic entries per user, and extend back to 2013 when the feature was released. This is going to be changed in the week of 2 March, to only store Notifications from the last 5 years, but up to 10,000 of them. This will help with long-term infrastructure health and help to prevent more recent notifications from disappearing too soon."

In T383948#11632425, @Ladsgroup wrote:

Instead of "long-term code maintenance" I'd say "long-term infrastructure health" otherwise looks great!

In T383948#11654202, @STei-WMF wrote:

"[...] This is going to be changed in the week of 2 March [...]"

Can I just check -- if I'm reading it correctly, @matmarex's comment in T383948#11625527 referred to giving at least two notices in Tech/News (the first one being well in advance) before anything changes. Is this not currently the plan re comms? /genq

In T383948#11625527, @matmarex wrote:

Also, I wish we could document a way to export your notifications before they're gone. I think the action=query&meta=notifications API would be an acceptable way to do this, were it not for the fact that it is limited to 50 notifications – could we temporarily increase this limit to 2000? (perhaps with a rate limit to avoid issues) [I can write the patch for this]

I think it would be more useful to have a JavaScript snippet, possibly hosted as a Toolforge tool, which handles the continuation to fetch all notifications instead of temporarily raising the limit.

Change #1251960 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/extensions/Echo@master] Create tests for NotificationMapper::deleteByUserAndAge

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

Change #1239793 merged by jenkins-bot:

[mediawiki/extensions/Echo@master] Delete old notifications of users

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

Change #1251960 merged by jenkins-bot:

[mediawiki/extensions/Echo@master] Create tests for NotificationMapper::deleteByUserAndAge

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

In T383948#11654613, @A_smart_kitten wrote:

In T383948#11654202, @STei-WMF wrote:

"[...] This is going to be changed in the week of 2 March [...]"

Can I just check -- if I'm reading it correctly, @matmarex's comment in T383948#11625527 referred to giving at least two notices in Tech/News (the first one being well in advance) before anything changes. Is this not currently the plan re comms? /genq

Now that the patch has been merged, assuming that this is the plan re comms, when should the second notification be made?

In T383948#11666369, @Legoktm wrote:

In T383948#11625527, @matmarex wrote:

Also, I wish we could document a way to export your notifications before they're gone. I think the action=query&meta=notifications API would be an acceptable way to do this, were it not for the fact that it is limited to 50 notifications – could we temporarily increase this limit to 2000? (perhaps with a rate limit to avoid issues) [I can write the patch for this]

I think it would be more useful to have a JavaScript snippet, possibly hosted as a Toolforge tool, which handles the continuation to fetch all notifications instead of temporarily raising the limit.

not a JavaScript snippet, but https://echo-chamber.toolforge.org/ now exists.

In T383948#11710350, @A_smart_kitten wrote:

In T383948#11654613, @A_smart_kitten wrote:

In T383948#11654202, @STei-WMF wrote:

"[...] This is going to be changed in the week of 2 March [...]"

Can I just check -- if I'm reading it correctly, @matmarex's comment in T383948#11625527 referred to giving at least two notices in Tech/News (the first one being well in advance) before anything changes. Is this not currently the plan re comms? /genq

Now that the patch has been merged, assuming that this is the plan re comms, when should the second notification be made?

I wouldn't do it since tech news always on the verge of explosion and I rather reduce the communication overload but if someone else decides to put it in tech news again, I wouldn't object

https://meta.wikimedia.org/w/index.php?title=Tech/News/2026/13&diff=prev&oldid=30270406

I read all of this, more or less, and didn't understand one thing. The change will be deployed today, the old notifications will be deleted, and the tool to download them before the deletion, in case somebody needs them (don't know why, but I think it's possible), will be published after this, next Monday? Can't you wait with the deletion, allowing the people at least a week to make a backup, please? Thank you.

Yeah, I was also thinking something along the lines of what @IKhitron wrote above. My understanding (correct me if I am wrong) is that https://gerrit.wikimedia.org/r/c/1239793 will result in notifications being deleted after it is rolled-out to wikis (I believe potentially when new notifications are delivered to users). Now that @Legoktm's echo-chamber tool exists, can we maybe temporarily revert that patch (or temporarily comment-out the code that would result in the additional notifications being deleted) until folks have had at least a little bit of time to use the tool to export their old notifications?

I will temporarily mark this task as a train-blocker (at least, until a decision on this is made), so that the train conductor is aware of this.

I have no problem with reverting the patch on the deployment if you find me one user on any wiki that complained about this changed when we announced it in tech news weeks ago. We really shouldn't work based on hypothetical user needs. If there are actually users who think they need their 5+ year old notifications, sure.

In T383948#11717686, @Ladsgroup wrote:

I have no problem with reverting the patch on the deployment if you find me one user on any wiki that complained about this changed when we announced it in tech news weeks ago. We really shouldn't work based on hypothetical user needs. If there are actually users who think they need their 5+ year old notifications, sure.

It's less about users complaining and more about this announcement https://meta.wikimedia.org/w/index.php?title=Tech/News/2026/13&diff=prev&oldid=30270406 of https://echo-chamber.toolforge.org in next week's TechNews which will be too late if you delete the notifications this week.

In T383948#11717686, @Ladsgroup wrote:

I have no problem with reverting the patch on the deployment if you find me one user on any wiki that complained about this changed when we announced it in tech news weeks ago. We really shouldn't work based on hypothetical user needs. If there are actually users who think they need their 5+ year old notifications, sure.

I mean... given that there's now been a tool developed to allow users to export their old notifications (when there wasn't one before), IMO we should allow them to do so before deleting them. Ultimately it is not my decision on whether to revert on -wmf.20 & -wmf.21 or not, but I would encourage doing so. I believe it would be a relatively easy thing to do in the grand scheme of things, as a courtesy to end-users before data starts to be permanently deleted.
I am also a bit saddened that - despite the 'two-notification before deletion' idea being raised in T383948#11625527 & T383948#11654613, there was no reply or confirmation about the comms plan before the patch in question was merged (at which point we risk it being a fait accompli that there was only one notification before deletion, as regrettably seems like it might end up being the case here, if e.g. the patch is not temporarily reverted).

In T383948#11717725, @Johannnes89 wrote:

In T383948#11717686, @Ladsgroup wrote:

I have no problem with reverting the patch on the deployment if you find me one user on any wiki that complained about this changed when we announced it in tech news weeks ago. We really shouldn't work based on hypothetical user needs. If there are actually users who think they need their 5+ year old notifications, sure.

It's less about users complaining and more about this announcement https://meta.wikimedia.org/w/index.php?title=Tech/News/2026/13&diff=prev&oldid=30270406 of https://echo-chamber.toolforge.org in next week's TechNews which will be too late if you delete the notifications this week.

I know. I am saying that announcing users to use something because we think they might need it (based on guesses since noone actually complained about this when originally announced) is not good use of our time.

I disagree that we should never do things based on anticipating users' needs, and/or that we should require users to specifically request (and/or complain about) something before we necessarily do it (if that is in essence what is being said here, with apologies if I am misunderstanding). I believe that it is reasonable to think/anticipate that several users of Wikimedia wikis will want to export / have a record of their 5+-year-old notifications -- and, presumably, the same anticipation may have been what lead to Tool-echo-chamber being developed.

Change #1254152 had a related patch set uploaded (by A smart kitten; author: A smart kitten):

[mediawiki/extensions/Echo@master] Revert "Delete old notifications of users"

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

Change #1254154 had a related patch set uploaded (by A smart kitten; author: A smart kitten):

[mediawiki/extensions/Echo@master] Revert "Create tests for NotificationMapper::deleteByUserAndAge"

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

Change #1254155 had a related patch set uploaded (by A smart kitten; author: A smart kitten):

[mediawiki/extensions/Echo@wmf/1.46.0-wmf.20] Revert "Create tests for NotificationMapper::deleteByUserAndAge"

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

Change #1254156 had a related patch set uploaded (by A smart kitten; author: A smart kitten):

[mediawiki/extensions/Echo@wmf/1.46.0-wmf.20] Revert "Delete old notifications of users"

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

Hi, the train is already a bit late and I do not plan to block proceeding with the train on this task, as announcements and discussion has taken place.

Just a remark. The people could not complain yet about publishing the new tool after the deletion, because the new tool wasn't published yet. After Monday they could start to complain.

Sorry, I didn't realize that the plan was to roll it out this week. I personally don't care very strongly about this (when I worked on Notifications like a decade ago it seemed pretty clear that they were ephemeral!), I mostly created the tool because MatmaRex asked for it in T383948#11625527 and it seemed fun. Not sure if he qualifies for Amir's request for "one user on any wiki" :-)

P.S. I don't think you need to actually revert, a config patch that temporarily extends $wgEchoMaxNotificationAge should be enough, right?

In T383948#11718469, @IKhitron wrote:

Just a remark. The people could not complain yet about publishing the new tool after the deletion, because the new tool wasn't published yet. After Monday they could start to complain.

I think there is a misunderstanding. This has been announced weeks ago: https://meta.wikimedia.org/wiki/Tech/News/2026/10 (explicitly, it went out on March 2nd) and my point is that noone since has complained or asked that they want to keep their old notifications so I don't think there is a need to accommodate that. YMMV.

Yes, I know, I translated it. I mean that there was no tool than, so people could not do anything. Now they could, if there would be enough time.

Change #1254154 abandoned by A smart kitten:

[mediawiki/extensions/Echo@master] Revert "Create tests for NotificationMapper::deleteByUserAndAge"

Reason:

not needed, just had to create this revert patch on `master` to make it easier to cherry-pick to `wmf/`-branches

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

Change #1254152 abandoned by A smart kitten:

[mediawiki/extensions/Echo@master] Revert "Delete old notifications of users"

Reason:

not needed, just had to create this revert patch on `master` to make it easier to cherry-pick to `wmf/`-branches

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

Change #1254156 abandoned by A smart kitten:

[mediawiki/extensions/Echo@wmf/1.46.0-wmf.20] Revert "Delete old notifications of users"

Reason:

this was -1ed, & the train has rolled to all wikis. feel free to restore if anyone wants to belatedly deploy this anyway, but it feels a bit late for this patch to still be open now. (also, as per legoktm in the task, a full revert probably wouldn't actually be necessary - just a patch to `mediawiki-config` to temporarily raise `$wgEchoMaxNotificationAge` to something large)

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

Change #1254155 abandoned by A smart kitten:

[mediawiki/extensions/Echo@wmf/1.46.0-wmf.20] Revert "Create tests for NotificationMapper::deleteByUserAndAge"

Reason:

per the reason for abandoning I62ba9ed261bcebd719c7564dbadde08c3f4ca9ed

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

(well, nobody can say that I didn't try 🤷‍♀️ I still think that this is a disappointing outcome that didn't have to happen; and to a point I do kinda think that it was unreasonable to have demanded/required "evidence that people need this change" in order to allow e.g. a temporary revert to have been deployed in this case, especially given the timeframes that were at work here before the train rolled forward. I wish there would have been responses to the query about communication plans before the patch was merged.)

In T383948#11718948, @Legoktm wrote:

P.S. I don't think you need to actually revert, a config patch that temporarily extends $wgEchoMaxNotificationAge should be enough, right?

FWIW I believe you are correct, thank you for pointing that out :) I won't upload a config patch for that here (both as this week's train has already finished running, so it seems a little late now; and because I anticipate that it would just be re--1ed), but anyone else is welcome to do so if they wish, of course.

Hello folks, Echo Chamber is currently broken. I don't know if the plan to delete notifications older than 5 years has already been enacted, but if so, I'll be the "one user on any wiki" mentioned above. I first saw the Tech News announcement on 1 April tried to use Echo Chamber then, got errors, and only got around to filing T422318 today. If the deletion hasn't happened yet, could it please be postponed at least until Echo Chamber is up and running for a week or so?

In T383948#11788145, @Toadspike wrote:

Hello folks, Echo Chamber is currently broken. I don't know if the plan to delete notifications older than 5 years has already been enacted, but if so, I'll be the "one user on any wiki" mentioned above. I first saw the Tech News announcement on 1 April tried to use Echo Chamber then, got errors, and only got around to filing T422318 today. If the deletion hasn't happened yet, could it please be postponed at least until Echo Chamber is up and running for a week or so?

Unfortunately, if I understand correctly, the deletion will have started happening as the train rolled out in the week-commencing 2026-03-16, as my proposal to temporarily prevent this from happening (to e.g. allow folks to use Echo Chamber) was not accepted. :/

If I understand the technical details correctly, if an account has received an Echo notification on a WMF wiki at any time since that week's train, that account's notifications (on that wiki) that were older than 5 years will have been automatically deleted.