Skip to content

Inconsistent behaviour between thread unfollowing and post unfollowing #1933

@trichoplax

Description

@trichoplax

Describe the bug
If the page state is inconsistent with the server state, so a user presses "unfollow" or "unfollow new" when not following, the result is different between unfollowing a thread and unfollowing new threads on a post:

  • For a thread, the request silently fails, changing nothing on the server (correctly), but leaving the page incorrectly saying "unfollow".
  • For a post, the request succeeds but changes nothing on the server (correctly), and changes the page to correctly say "follow".

To Reproduce
Steps to reproduce the behavior for a thread:

  1. Go to a post with a comment thread under it that is being followed by the user.
  2. Open it again in a separate tab.
  3. Change the state in one tab by pressing "unfollow".
  4. Switch to the other tab and press the same again.
  5. See nothing happens from a user perspective.
  6. See a 400 error in the browser's developer console.

Steps to reproduce the behavior for a post:

  1. Go to a post for which the user is following new threads.
  2. Open it again in a separate tab.
  3. Change the state in one tab by pressing "unfollow new".
  4. Switch to the other tab and press the same again.
  5. See the link change from "unfollow new" to "follow new".
  6. See a 200 response in the browser's developer console.

Expected behavior
The behaviour should be the same for a thread as for a post. Which behaviour should be adopted for both? From a user perspective, having the link update to say the correct thing seems better. For the response status, I don't know whether it's better to return a 400 (as is currently the case for a thread) and make the page update to say "follow" due to the failure, or to return a 200 (as is currently the case for a post) and make the page update to say "follow" since that will be the case whether the user was already following or not.

Should a 400 be reserved for the case where the server is not already in the state being requested, and there is a failure preventing the state from being changed? Should the case where there is no change on the server because it was already in the state the user was requesting result in a 200?

Metadata

Metadata

Assignees

Labels

area: backendChanges to server-side codecomplexity: easyIssues that should take limited effort to resolve/fix/build.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions