Spooky tracking happenings 👻


(Leo McArdle) #1

There are things like the following I’ve been noticing for months, but never filed a report for, because I could never reproduce them consistently. But, finally, accidentally, I’ve caught one on camera! (So please forgive the pausing and confusion reflected in my cursor movements.)

The things to look out for are:

  1. Unread being empty
  2. #feature showing as ‘Normal’ (despite being tracked, as shown in my preferences) and only showing as ‘Tracked’ on a refresh
  3. A topic mysteriously appearing in unread (from days ago, from the howto category)

The 2nd point is somewhat similar to a common bug I see (but have never been able to reproduce on video) where I’ll click on a topic from new in a category I’m tracking, but its own status won’t show as tracked unless I refresh the page. (I wonder if that’s related to this.)

Just before recording this I was trying to reproduce that bug by tracking #bug, and then clicking on one of it’s topics from the unread tab. I couldn’t, but upon un-tracking #bug, my unread tab was filled with about 20 closed topics in #bug from around 2015, which seems to be the same bug as point 3.

I don’t understand why this could be happening. :ghost:


(Jeff Atwood) #2

What are the repro steps?


(Leo McArdle) #3

There are two bugs here.

I can’t consistently reproduce the first, where the correct notification level is only shown after a refresh (of a category, or a topic). It’s been happening to me for months, but whenever I try to reproduce it, it doesn’t happen.

The second, which I think is a bit more minor, but still a nuisance can be reproduced (for a limited time only) like so:

  1. Clear /unread
  2. Track a category currently set to ‘Normal’
  3. Go back to /unread and observe posts not previously in it

I’ve been able to do this with a number of categories, but only once for each. Once I’ve dismissed the posts from unread, they never appear again.

Consistently reproducing it takes a little more work, so hold onto your hats, it’s gonna get a bit crazy:

  • Go to unread in a category of your choosing which has a notification level of “Normal”, observe nothing there:

  • List all the currently tracked topics in that category (and remember, or take a screenshot of them):

  • Enter a topic from that category not on that list:

  • Start tracking the category
  • Again list tracked topics in that category
  • Observe the topic you just opened in that list:

  • Go to unread, and again observe that topic in the list:


TL;DR

So, the bug here is that previously opened topics in a category become tracked, and appear in unread (unless previously dismissed), when the category is tracked, whereas nothing happens to old not-opened-before topics.

To me, what should happen is either:

  • Nothing changes about the notification status of old topics in a category when it becomes tracked, previously opened or not.

or

  • All old topics become tracked when the category is tracked, but are automatically dismissed, so only new activity appears in the unread tab.

I lean towards the second solution, provided explicitly set notification levels on topics are kept.

I haven’t investigated how this works with other notification levels, I imagine its the same, but I feel it would confuse things for the time being.


(cpradio) #4

So in relation to

What part is considered as “not working as expected”?


(Leo McArdle) #5

2 parts:

The first would be topics not being properly implicitly tracked. If they were, all of the topics from #praise should appear in this step:

It seems like that list is just showing topics with a tracking record of “tracked”, and that’s not working as expected. What would be, would be showing all topics with a tracking record of “tracked”, and all topics which are in a tracked category. (The same would go for watching.)

Furthermore, while this makes sense:

It seems like the same functionality is missing when a user tracks a category. Shouldn’t a tracking record also be created when there is a new post in a topic?

The second would be the appearance of seemingly arbitrary topics in unread when you track a category, (I assume a side effect of changing the tracking state of past topics from regular to tracked), which could be fixed by automatically dismissing those topics from unread.


Category creep and information overload
(Mittineague) #6

What are your Preferences -> Other
Consider topics new when
and
Automatically track topics I enter
settings?


(Leo McArdle) #7

I haven’t viewed them yet

never


(David Taylor) #8

This is something I found a while ago, and a thread can be found here (not entirely sure why it got moved from #bug to #feature).

The thread is quite confusing as I originally thought the problem was caused by the initial import from phpBB. So here’s an attempt to summarise:

It comes down to the fact that a topic cannot be both new and unread simultaneously:

  • Even though it’s implicitly tracked, topic does not show up in unread because the user has never viewed it
  • Topic does not show up in new because it is beyond the threshold of whatever your “Consider topics new when” setting is

It’s a hard problem to solve, because having every single old topic in a category appear in your ‘unread’ tab is really not a good user experience.

“Automatically dismissing” them is quite expensive database-wise (a new TopicUser record would have to be created for every single topic in the category you just tracked).

We didn’t really come up with a tidy idea to solve the problem, and the discussion kinda died. One option that @sam came up with was

At the time, I thought this might be a good idea:

But

TL;DR: I don’t have a solution, but hopefully this makes the problem clearer :wink:


Old unread topic doesn’t show up as unread in tracked category
(David Taylor) #9

And for the other issue in this thread:

I can reproduce this consistently here on meta for categories. Repro steps:

  1. Go to your user preferences, remove all tracked categories
  2. Go to a category page, e.g. #meta, and observe that the ‘notification level’ indicator is “normal”
  3. Go immediately to your user preferences, by clicking your avatar in the top right, then the cog
  4. Add the category you just visited, e.g. #meta, to your “tracking” categories
  5. Press “save changes”
  6. Press the back button in your browser to return to #meta, and observe that the ‘notification level’ indicator is still “normal”
  7. Refresh the page, and observe that the ‘notification level’ is now “tracked”

If you replace step 6 with visiting the category page by some other route, the tracking status appears correctly.


(Leo McArdle) #10

From a practical perspective, that doesn’t make sense to me. If I buy a book and put it on my shelf having not opened it, it is both new and unread.

Wouldn’t it be possible to have an old topic (with no tracking record) only appear in unread when there’s new activity on it?

So, just as a tracking record is created on new activity for topics in watched categories, a tracking record would be created on new activity for topics in tracked categories.

Combined with the above, couldn’t we just dismiss topics where the tracking record has been changed to “tracking” as a result of tracking the category, which would mean the same user experience, without any additional database writes? (If I understand how tracking records, dismissing and TopicUser relate.)

This way, it seems to me, we could have a mailing list experience for tracking too! :smile:


(David Taylor) #11

Sure, I agree. I was talking purely about how it currently works in discourse.

I believe @sam thought this would have major performance issues

I’m 99% sure a new record isn’t created for tracked topics - @sam said “created when we notify users”, and tracking doesn’t cause notifications. Maybe fixing this is the solution :slight_smile:


(Leo McArdle) #12

Do you know if there’s an architectural issue which means the new/unread either/or has to be the case?

Indeed, I was proposing this as a solution which seems to not have any major performance issues.


(David Taylor) #13

I assume it’s by design - having a topic listed on the new tab and the unread tab would be a bit weird.

Taking your book analogy, while it can be both unread and new, you can’t put it on your “new” shelf and your “unread” shelf simultaneously :wink:


(David Taylor) #14

Ok… I’ve done some testing in my dev environment. As a simplest possible repro:

  1. Set previous visit timeout hours site setting to 0, to make testing quicker
  • User A sets “Consider topics new when” to “created since I was last here”
  • User A sets Category1 to tracked
  • User B posts in Category1
  • User A observes the topic in ‘new’, but does not open it
  • User A leaves the site
  • User A comes back to the site later, and User B’s post is gone from the ‘new’ tab
  • User B posts again in the same topic
  • The topic does not appear in either ‘new’ or ‘unread’ for User A, even though they are tracking the topic

That same repro works for ‘watching’ a category as well. A notification is sent, but no TopicUser row is created (checked on the rails console). It seems that this:

is not happening for some reason, both for watched and tracked categories.


(Leo McArdle) #15

Would it though? We already have topics listed in the latest tab and the new/unread tabs simultaneously. And the two (new and unread) are for different purposes: new is “show me the newest topics on this site” and unread is “show me topics I’ve expressed an interest in, but haven’t (finished) read(ing)”. For new to achieve its purpose it has to have unread topics in it which are new, and for unread to achieve its purpose it needs to have new topics in it which are unread.

Currently the unread tab is rather dysfunctional.

Interesting, thanks for doing all this investigation! So it would seem like if this did actually happen (or more specifically, a TopicUser row was created on topic update, rather than notification, to include tracked categories), then our problems here would be solved. @sam thoughts?