New / Unread counts missing when "too many tracked topics"

Feature
1

I have enough topics in new and unread that I get the new warning - but as of earlier the numbers aren’t showing?

Is this intentional? Have tried a hard refresh.

1 Like
2

According to @Sam that warning - while not noticably affecting performance - can bring the numbers to illogical values.

https://meta.discourse.org/t/new-indicator-is-showing-wrong-numbers-again/25860/18?u=kuro

Filed Under: Probably not intentional

3

Intentional – the numbers you get back would be invalid anyway due to the warning you see.

I asked @sam if he could change it to show New (*) and Unread (*) to more clearly indicate the weird state but he said it would be a lot of work, and we already have the notification, so…

4

But if the warning pointed out that “too many” was indeed over $maxTracked (so 500 by default) then the invalid numbers would make sense. Currently I’ve gone from having numbers, to having no numbers while still being told it’s too many.
This isn’t user friendly.

What weird state happens? Before the warning, it always showed a combination of numbers which added up to 500. Once explained (maybe explain in the warning) that made sense. This current way of doing it does not IMO.

5

You’d have to ask @sam about that, he felt rather strongly it was best to show nothing since the numbers would be nonsensical at that point.

6

I want to work a bit more on the root cause before fighting in the (*) change. Lots of code expects the counts to be numbers so it is a rather extensive change to get in.

We should not be allowing people to treat a topic that is 12 months old as “new”, we need some saner caps. This would actually solve the issue for you at least here.

On sites like http://www.helloforos.com/ where they are churning 200 new topics a day we need a way to wind down the caps to and set them globally so, new === 24 hours or less old for everyone (with no user options)

I would like to first address some of the root issues before coming back to the UI here

3 Likes
7

Yeah, that’s fair enough I guess. Maybe just have it so if a user’s at the limit, and another new topic is created, that the oldest one is no longer treated as ‘new’ and the new one is.

Hiding the numbers (in any way) is confusing - (*) is better but just showing the numbers makes sense when the limit is known. Appreciate it’s a work in progress, and no idea if something funky happened behind the scenes though.

Maybe put the limit in the message (e.g. Warning: you have more than 500 new and unread…) - it’s clearer.

2 Likes
8

I think I am ready to put this to rest post this commit: FEATURE: implement capping of new/unread · discourse/discourse@335be27 · GitHub

Copied from commit message:

We cap new and unread at 2/5th of SiteSetting.max_tracked_new_unread

This dynamic capping is applied under 2 conditions:

  1. New capping is applied once every 15 minutes in the periodical job, this effectively ensures that usually even super active sites are capped at 200 new items (+ number of new topics created in 15 minutes)

  2. Unread capping is applied if a user hits max_tracked_new_unread,
    meaning if new + unread == 500, we defer a job that runs within 15 minutes that will cap user at 200 unread

This logic ensures that at worst case a user gets “bad” numbers for 15 minutes and then the system goes ahead and fixes itself up

This resolves the issue completely even for super active sites like @charleswalter heloforos, with ZERO config needed by users or admins, and no confusing message to end users.

7 Likes
9

I am sorry, I am having trouble understanding this commit message:

Do you mean the numbers you show on the New/Unread Tab?
Am I literally losing tracked topics (in terms of position and blue/grey bubble)?
Why 2/5th? That seems like an arbitrary number to me. Could you explain this number, please?

Other than that, thank you for working on this.

Filed Under: Not sure if I will miss this bar!

10

If you hit 500, we automatically press “dismiss new” and “dismiss unread” for you on the 300 oldest things. That’s how I understand it. Is this correct @sam?

So you are automagically bumped down to 200 things being tracked, once you hit 500.

1 Like
11

I am allowing for 200 new as well. So worst case you have 200 new + 200 unread after an auto clear, I wanted to allow a big buffer here to eliminate this magic behaviour triggering too often

On second thought I may be able to push this upto a combined 400, which means we have a total of a 100 buffer which is fine

1 Like