Nanosync / pe

0 stars 0 forks source link

Repeatedly undoing causes the application to hang for about 10 seconds #9

Open Nanosync opened 4 years ago

Nanosync commented 4 years ago

Reason: The app should not hang when undoing commands.

Steps to reproduce:

  1. Type many valid commands
  2. Press the up arrow key and hit enter, repeat several times.
  3. The application becomes completely unresponsive.

After waiting: image.png

nus-pe-bot commented 4 years ago

Team's Response

I am unable to reproduce the reported bug.

The steps are not very specific (i.e. "many" commands, and "several times"). So I entered a hundred valid commands before undoing all these commands as follows.

  1. Enter addexpense d/test p/1 c/food 100 times
  2. generate statistics using statsbasic (the screenshot some stats command's page)
  3. Undo using the input history feature until there are no commands to undo (as the result display in the screenshot shows that there are no undoable commands left).

Doing these steps, I have not observed any delay at all. Hence, I am categorizing this as cannot reproduce.

I suspected that the delay, if any, would be due to the user rapidly undoing commands (e.g. 4 - 5 undos / second). So I repeated the above steps but entered the undo command rapidly and not at a rate that would be similar to normal usage (normally undo would have a much larger delay between undos due to the need to type or copy paste and enter. In this case too, I was unable to reproduce the bug.

Additionally in this case, I would categorize this report as not in scope. I feel there it is not warranted for us to be penalized as neither the undo feature nor the input history feature was meant for such abusive usage. Similar to the behaviour expected regarding graceful recovery from intentional sabotage from intentionally corrupting .json data files, as the application reportedly recovers after waiting, I believe that this issue can be rejected if this was how the bug occurred(i.e. rapidly entering undo commands).

While the application becoming unresponsive would be a considerable inconvenience, as it does not fatally crash and is still usable after waiting, thus it does not warrant a High severity as it would still be usable (especially since there is no fatal crash). Hence, I am decreasing the severity to Medium.

Items for the Tester to Verify

:question: Issue response

Team chose [response.CannotReproduce]

Reason for disagreement: Thank you for the response.

I believe that rapidly performing a command repeatedly (mass undo) is not sabotaging the application, and is something the target user can do (type fast and is reasonably comfortable using CLI apps). It can be a typical user action, such as when the user feels that all the data keyed in for this session should be reversed, rather than deleting the entire configuration file and keying in all his/her budget data from scratch again.

Based on the NFRs:

It is true that in typical usage, one would not add 1000 expenses and undo all the actions. But for typical usage, a user could perform other actions and try to undo really quickly, only for the application to hang or act really sluggishly.

I've reproduced the bug again, and attached a log below. In the logs, I've typed 145 addexpense commands based on the given command in the response, and performed several undo actions rapidly. This time, the application suddenly threw an exception (included in log), and ceased to function - showing an empty list (grey background) although you could still type commands.

MooLahLog_21-11-2019.txt

Thus, I don't believe that the response should be rejected or response.CannotReproduce.


:question: Issue severity

Team chose [severity.Medium]. Originally [severity.High].

Reason for disagreement: