Open Nanosync opened 4 years ago
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.
addexpense d/test p/1 c/food
100 timesstatsbasic
(the screenshot some stats command's page)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
.
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.
Thus, I don't believe that the response should be rejected or response.CannotReproduce
.
Team chose [severity.Medium
].
Originally [severity.High
].
Reason for disagreement:
Reason: The app should not hang when undoing commands.
Steps to reproduce:
After waiting:![image.png](https://raw.githubusercontent.com/Nanosync/pe/master/files/2bf96a95-e88a-416d-9fbd-e53e2f28e1c0.png)