The discussion revolves around a bug in Discourse where reply counts on topics with auto-deleting posts are incorrectly displayed. Stephen noticed that the unread reply count on a topic was 303, but after opening it, the count dropped to 1, despite only one reply remaining. codinghorror confirmed this is a long-standing issue affecting both automatic and manual deletions, with the count only updating upon topic visit. Stephen asked about the difficulty of fixing it, and sam explained that fixing it would be extremely complex, requiring a custom data store and potentially taking multiple months, as the system relies on post number deltas rather than counting unread posts directly.
Just noticed that when it had unread replies, the unread reply count on the Postgres 12 announcement topic was at 303 (blue circle with 303). Upon opening the topic the latest reply the count changed to 1.
The topic is set to auto delete replies older than 5 days, there’s currently only one reply on that topic.
Looks like the reply count on auto pruning topics with unread posts isn’t calculated correctly?
This was on mobile, I didn’t think to check desktop before opening the topic and marking it read.
Yes, this is a known issue that has existed in Discourse since practically V1. Lots of deletions then a reply will always cause this mismatch, until the next visit of the topic. Doesn’t matter if they are automatic or manual deletions.
Just to close the circle here, a fix here is massively extremely unpleasant, backend never actually counts specifically how many posts you have unread, it relies on a delta of highest_post_number and the last post_number you visited in topic users.
If I had to put a number on this, if my only job was to fix this bug it would take me multiple months to fix and I would have to invent a custom data store to get it going. Running a count(*) query on every unread topic is off the table.