It seems like the problem is that Echo doesn't really have a way to know that multiple events generated on the server at different times (as part of a job queue, for example) should be consolidated.

Our goal is simply to avoid spamming the user. We don't really need to convey much information here, just "You have new images ready to review". The place they go to review will always be Special:SuggestedTags, regardless of the nature or number of the images they have uploaded.

@Mholloway suggested two possible work-arounds here:

Hmm, I guess you could query the echo_notification table at that point to check for too-recent notifications, but that doesn't feel like a very elegant solution

If we only want users to receive one notification about this per N minutes, then maybe a better way to handle it is to run a periodic job every N minutes to send a single message to everyone with a newly labeled image in that window, rather than immediately notifying as soon as the labels come in for each individual image

I agree that the first approach feels a little more like a hack. I could probably muddle through the PHP code to figure it out though. The job-based approach might be better, but I don't know much about how to implement it; someone else should pick this up in that case. At the very least I'd need to be able to ask a lot of questions about how the job system works.

For the latter option, I was using the term "job" loosely, and probably shouldn't have — I meant "job" in the general sense of "task," rather than a thing to put on the MW Job Queue. I was thinking more along the lines of a maintenance script that could run periodically on a cron job.

The current notification bundling is working exactly as intended: unread notifications are bundled; once read, they unbundle; Special:Notifications doesn't bundle.

So:

1. we either change Echo's bundling rules (but there are good reasons for not rebundling read events, likely a lot of work)
2. just leave things be - this is how it was designed to work. Only unread messages matter - no-one cares about unreads. And those that do can selectively turn off this notifications category.
3. we send fewer notifications (which means a more vague description - it's no longer about specific files)

I have a patch ready for #3 (where users will not ever get another "Suggested tags are ready for review" notification until they've read the previous one), assuming we're not happy with #2 (do nothing, current situation is fine)
It's essentially similar to current situation (new notifications will end up bundled with existing, or will cause a new bundle when none were unread), except that there'll be far less 'unbundled after read' noise.

Change 586359 had a related patch set uploaded (by Matthias Mullie; owner: Matthias Mullie):
[mediawiki/extensions/MachineVision@master] Self-bundle notifications

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

Thanks! #3 does seem like what we have to go with. The logic of the patch seems reasonable to me. I'm looking forward to the code review 😺

In T248322#6032329, @matthiasmullie wrote:

The current notification bundling is working exactly as intended: unread notifications are bundled; once read, they unbundle; Special:Notifications doesn't bundle.

So:

1. we either change Echo's bundling rules (but there are good reasons for not rebundling read events, likely a lot of work)
2. just leave things be - this is how it was designed to work. Only unread messages matter - no-one cares about unreads. And those that do can selectively turn off this notifications category.
3. we send fewer notifications (which means a more vague description - it's no longer about specific files)

I have a patch ready for #3 (where users will not ever get another "Suggested tags are ready for review" notification until they've read the previous one), assuming we're not happy with #2 (do nothing, current situation is fine)
It's essentially similar to current situation (new notifications will end up bundled with existing, or will cause a new bundle when none were unread), except that there'll be far less 'unbundled after read' noise.

Tested this out locally, everything seems to work as expected. I didn't know about the EchoNotificationMapper class that lets you determine a user's unread notification count pretty easily. Merging this now.

I'd recommend some serious QA-ing on Beta once this is up there to ensure the behavior is falling more line with what people want now. Single uploads, batch uploads with UW, etc.

Change 586359 merged by jenkins-bot:
[mediawiki/extensions/MachineVision@master] Self-bundle notifications

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