Improve concurrent updates of labels
Summary
Concurrent updates of some parts of issues are problematic, especially around labels, whether via boards or sidebars, resulting in really easily overlooked overwriting.
Steps to reproduce
- Open two tabs: one showing a board with issues and one showing an issue (say
#42
) that is also present on the board. - On the board tab, change the list in which issue
#42
appears using drag and drop. - On the issue tab
#42
, don't refresh and add a label, any label, especially one unrelated to the board's lists. - On the board tab, refresh. Issue
#42
is back on the previous list.
There are many other scenarios as to how this could happen.
Example Project
https://gitlab.com/lloeki/test/boards
What is the current bug behavior?
Concurrent use silently overwrites changes.
What is the expected correct behavior?
Concurrent use should not have such silently overwriting behaviours.
Relevant logs and/or screenshots
Output of checks
This bug happens on GitLab.com
Possible fixes
Throwing some random ideas that crossed my mind:
- General: concurrent update should be guarded in some way, such as optimistic locking, displaying a warning about someone having modified the issue concurrently, and ideally no loss of the user content (especially when editing a description or comment) so that he can take note of his rejected input (copy/paste, screenshot...)
- General: Some more areas should be updated live, reducing the risk of loss due to concurrent updates: in the above case, if the label list as well as the position on board were live updated, the risk is much smaller.
- Labels (and lists such as assignees): possibly update labels as a delta, not as a replace (i.e don't do
labels = ["new", "kept"]
but compute delta and applylabels += ["new"]; labels -= ["removed"]
)
Edited by Loic Nageleisen