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:
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.
I’ve been trying to find out where last_visited_at is updated so far I have found:
The spec successfully tests a call to TopicUser::track_visit updates the value.
TopicUser::change - change in notification level watching/tracking etc)
TopicUser::update_last_read - keeps track of the last read post.
The problem seems to be:
There are no calls to TopicUser::track_visit outside of the spec.
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.
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.
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. .
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.
