Is `topic_users.last_visited_at` supposed to be updated on every visit?

(Dean Taylor) #1

Am I completely misunderstanding entirely what these values are for?

I’ve been using Data Explorer to review activity and noted that topic_users.last_visited_at didn’t seem to be updating / showing topics I have recently visited.

Is topic_users.last_visited_at supposed to be updated on every visit to a topic?

Here is the Query I was using with Data Explorer.

-- [params]
-- int :user_id = 1

SELECT
    topic_id,
    last_visited_at,
    first_visited_at
from topic_users
WHERE
    user_id = :user_id
ORDER BY
    topic_users.last_visited_at DESC

When this is executed I see NULL’s for topics I have visited and even some I have created:

Pasted image869×230 7.95 KB

Scrolling down further to get to some dates I see:

Pasted image881×212 10.4 KB

Where I have visited each of these topics today 2016-04-07, however it looks like only the first visit was stamped.

So are last_visited_at and first_visited_at updated correctly - or am I just misunderstanding entirely what these values are for?

Is there a timestamp that’s updated when a user visits a topic?

NULL first_visited_at dates in the topic_users table
(Mittineague) #2

Hmmm. Odd.

I just tried it and had similar results. NULLs until back to April 3

I was thinking that was around when I last upgraded, and since I always do a db:migrate after I update that maybe that was what was needed.
But no joy.

Then I worried that maybe something broke with the upgrade. So I checked using different user ids.
One had NULL back only 2 days, and another had no NULLs at all and was up-to-date.

Very puzzling.

(Dean Taylor) #3

I’m pretty sure I’m ready to call this a bug.

I’ve been trying to find out where last_visited_at is updated so far I have found:

  1. The spec successfully tests a call to TopicUser::track_visit updates the value.
  2. TopicUser::change - change in notification level watching/tracking etc)
  3. TopicUser::update_last_read - keeps track of the last read post.

The problem seems to be:

  1. There are no calls to TopicUser::track_visit outside of the spec.
  2. TopicUser::update_last_read only updates the last_visited_at value when:
  • “The user read at least one post in a topic that they haven’t viewed before”

I’m thinking that the following should be reviewed:

1. Should there be an explicit call when track_view is set when requesting the topic? I think there should be.
2. Change the UPDATE_TOPIC_USER_SQL to also update last_visited_at time as used in TopicUser::update_last_read so the value is kept up to date along with reading times.

3. There is a possibility that last_visited_at and first_visited_at are being set to NULL here when TopicUser::change tracking state changes:

But I don’t know enough / have a test environment to check for sure.

4. If point 3 above is not where the NULL is coming from there is either TopicUser rows being put in the table with initially last_visited_at and first_visited_at set to NULL or somewhere else they are being set to NULL.

Thoughts?

(Mittineague) #4

I just ran this

SELECT *
from topic_users
WHERE
    last_visited_at IS NULL
    AND ( last_read_post_number > 0 
       OR highest_seen_post_number > 0 )
ORDER BY id DESC

The few results were odd but not totally unexpected.
Members were Watching the category when they visited the topics,
The topics were subsequently moved, unlisted, deleted, and one the category permissions were changed.

When I saw these back in April I wrote them off as most likely a set-up quirk rather than a Discourse Bug. .

Are you still getting such rows added?

(Sam Saffron) #5

Well actually…

This seems to be working fine for me.

The null rows will usually be users who never really visited and instead got a row there cause they were watching a category or had mailing list mode enabled. As soon as we send a mail out to a user we add a row in topic users.

(Dean Taylor) #6

That code was added after the time of my report / investigation: