Moving a topic to another category doesn't propagate

Contribute Bug

AI-generated summary

A bug was reported where moving a topic to another category doesn’t propagate to users who are still viewing the topic. Falco provided steps to reproduce the issue, which was then compared to a similar issue reported on meta (TechnoBear).

Mittineague suggested this is a “transaction” type of issue, where simultaneous edits can cause conflicts. Falco proposed a simpler approach, automatically updating the topic state if the user hasn’t clicked the edit button.

jeremylan attempted to reproduce the issue and found that the category and title don’t update immediately, but replying doesn’t revert the topic to the original category. He suggested triggering a refresh event for category and title changes.

tgxworld investigated the issue and implemented a fix (tgxworld), publishing changes to TopicView when the topic changes. jeremylan and sam confirmed the fix works, with title and category updates now being broadcasted correctly.

1

Steps to repro:

  1. User A create a Topic on Category I

  2. User B enters topic

  3. User B moves Topic to Category II

  4. User A still on topic, but it didn’t updates the category

Aggravating:

  1. User A, still on topic, makes a small edit on the text. Topic gets moved back do Category I.
9개의 좋아요
2

I may be wrong, but this sounds similar to the issue reported here and apparently fixed.

3

Sort of. But ours specifically dealt with a restricted category, @falco’s doesn’t. You can use two public categories and produce the same results.

3개의 좋아요
4

It is a “transaction” type of thing.

Similar to when a member makes a poorly formatted post, the tries to edit it.
If at the same time a Mod fixes it before the member finishes the Mod fix will be replaced with the member fix when they Save.

I think most times the chances of more than one working on a post / topic at the same time are rare. Though the problem has come up before, wiki edits in particular.

I know databases can lock transactions, but I don’t know how it could be dealt with here.

I have seen it suggested to prevent further topic replies if another is in the process of replying, which I think is a poor idea.

But it might be nice to have on a per post level.

2개의 좋아요
5

I’m thinking on a rather simpler approach here:

If the user hasn’t clicked on the edit button yet, the topic state (title, category) should update automatically.

7개의 좋아요
6

Hi

I tried to repro and that is what I found, I could not repro the ‘aggravating’ from OP.

  • userA and userB have the topic open in the editor, topic category is I.
  • userA changes topic to category II and posts something
  • userB receives the reply immediately, but for him topic is still in category I, i.e. the post count and content refresh but the category and title do not.
  • if userB replies (for him the post is still category I) this does NOT put the topic back to category I. If userB leaves the editor he will see the new category for the topic in the topic list.

I think the category and title change commit button should really trigger the same type of refresh event for category and title that is triggered by the reply button if that makes sense.

2개의 좋아요
7

I’m having a look at this.

2개의 좋아요
8

We’ll now publish the changes to TopicView when the topic changes.

https://github.com/discourse/discourse/pull/4139

A few improvements I can think of but will be much trickier to implement:

  1. Perhaps we should reload the topic object globally when the topic changes?
  2. Publish a notice in the composer when user is editing a topic that has been changed.
4개의 좋아요
9

I’ve tried your changes on my instance @tgxworld and it works perfectly, title update and category update are broadcasted now! Great work!

1개의 좋아요
10

I just tested this multiple times on meta from all the places and seems to work fine

4개의 좋아요