Page MenuHomePhabricator
Create Task
Maniphest T222891

Inform users if there was no response from the server
Open, MediumPublic
Actions

Description

Motivation
In case of missing signal, or the server not responding to the client anymore, users should be aware that their save may or may not have gone through. Different ues cases are:

  • The network dropping (or changing) mid request
  • The api never responding at all
  • The api responding in a way we don't understand (a malformed response)

In all of these cases, we follow the general error handling pattern, but we want to give a meaningful error message

Acceptance Criteria

  • After TODO seconds of not hearing back from the server, show an error message TODO including it may or may not have been saved!, and that we will not be able to tell them in an overlay to the user as shown in the mock
  • Initially the popup appears on top of the content page (between grey bar and content, if possible, but if not possible, then above the grey bar)
  • Users can scroll content "behind" the popup
  • The error message does not disappear until the error is resolved (successful save, cancel button or leaving the page)

Related Objects
Search...

StatusSubtypeAssignedTask
 OpenNoneT219886 Unhappy Editing Paths
 OpenNoneT222891 Inform users if there was no response from the server

Event Timeline

• Lea_WMDE created this task.May 9 2019, 2:25 PM
• Lea_WMDE updated the task description. (Show Details)May 23 2019, 11:58 AM
• Lea_WMDE triaged this task as Medium priority.May 23 2019, 1:28 PM
• Lea_WMDE updated the task description. (Show Details)
• Lea_WMDE merged a task: T222617: Handle failures where we do not know if the save has been successful or not.
• Lea_WMDE edited parent tasks, added: T219886: Unhappy Editing Paths; removed: T222617: Handle failures where we do not know if the save has been successful or not.
• Lea_WMDE changed the task status from Open to Stalled.May 27 2019, 1:25 PM

We are handling the case "we don't know if the save was successful or not" as one of the instances of the generic "sth went wrong", since we want the same behavior: Once users know that we cannot confirm the save went through, they should be able to edit and save again. In the best case, they save again without any more changes to the item, and are then sure their edit has been published. In the worst case they change something else, the first edit went through, and other people have edited the item in the meantime as well. This would mean the user is working on an old version of the item and might then run into an edit conflict on save.

• Lea_WMDE updated the task description. (Show Details)May 27 2019, 1:27 PM
Tarrow added a comment.EditedMay 28 2019, 8:58 AM

In the worst case they change something else, the first edit went through, and other people have edited the item in the meantime as well.

I understand the reasoning here. I was particularly thinking about a variant of this scenario: no one else has edited but this user changes his second edit to conflict with his first.

For this reason I was suggesting that that the behaviours for "something went wrong" vs "we don't know if it worked" should differ.
"something went wrong" = still possible to edit text boxes and click publish again.
"we don't know if it worked" = not possible to edit text boxes. Only publish is an option.

We could always do the same action in both situations to compromise on complexity but with the knowledge that in either scenario it might put the user into an inescapable path.

• Hanna_Petruschat_WMDE subscribed.EditedMay 28 2019, 9:57 AM

@Tarrow Thanks for the write up!
One more suggestion: Assuming that no one likes to see an error message and we already know, that hitting publish again could solve the issue: Could we automatically hit publish again in the background when we didn't hear back from the server and only if it doesn't work after 3 tries we then let the user know that unfortunately they have to reload because we didn't manage?

@Lea_WMDE this might be a product question as well: How much cognitive load do we need to put on the user for the sake of transparency?

Aklapper changed the task status from Stalled to Open.Aug 16 2022, 9:04 PM

The previous comments don't explain who or what (task?) exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"). Hence resetting task status, as tasks should not be stalled (and then potentially forgotten) for years for unclear reasons.

(Smallprint, as general orientation for task management:
If you wanted to express that nobody is currently working on this task, then the assignee should be removed and/or priority could be lowered instead.
If work on this task is blocked by another task, then that other task should be added via Edit Related Tasks... → Edit Subtasks.
If this task is stalled on an upstream project, then the Upstream tag should be added.
If this task requires info from the task reporter, then there should be instructions which info is needed.
If this task needs retesting, then the TestMe tag should be added.
If this task is out of scope and nobody should ever work on this, or nobody else managed to reproduce the situation described here, then it should have the "Declined" status.
If the task is valid but should not appear on some team's workboard, then the team project tag should be removed while the task has another active project tag.)

Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits