Subtask creation form submission race?
I encountered what seems to be some form of database or form state corruption, while creating multiple subtasks for a task on our local Redmine instance (running SVN r3608).
Steps to reproduce:
- Create a parent task
- Open up more than one subtask creation form from the parent task's Subtask "add" link (that is, in separate browser windows / tabs)
- Fill in each subtask's Subject field, without submitting them
- Submit each form (window/tab) in succession, without strictly waiting for the previous submission to complete
The above shouldn't cause any trouble or corruption, because each form submission should be logically independent, but this doesn't seem to be the case, as can be seen in this example i created on demo.redmine.org:
(The subtask creation forms were submitted in the above order (1, 2, 3), but as can be seen from the issue numbers, Test child 3 happens to have been created before Test child 2.)
The exact symptoms of the corruption seems to vary; in the above example, it can be observed that although #28910 and #28909 both have "28907" in their parent field, they display each other as their respective parents in their parent trees: in other words, their parentage is displayed as #28907→#28909→#28910 and #28907→#28910→#28909, instead of #28907→#28910 and #28907→#28909.
Other symptoms i've observed:
- In the local case, one child ended up displaying all the other children as a sequence of nested parents (despite all the children having their parent field set to the same root issue)
- The parent issue sometimes displays only some of the children (despite all their parent fields being set), or none
- Trying to update the affected issues result in server-side Internal errors, or in one case a "Parent task translation missing: en, activerecord, errors, models, issue, attributes, parent_issue_id, not_a_valid_parent" error
I could only solve this so far by deleting and recreating all the affected issues, without form submission overlap. (Deleting the children alone seems insufficient; subsequent recreation fails.)
(I don't know if this problem is specific to subtask creation, or affects all task creation; i'm not sure how to test the latter.)
#2 Updated by Piet Delport almost 3 years ago
That is, i've seen it not only with subtask creations, but with parent reassignments and other operations involving parent / child task relationship changes.
Other concurrent operations don't seem to have any problems: only hierarchy changes seem to trigger the corruption, and the symptoms seem to be consistent with nested set left/right boundaries going haywire.