Race condition: Incorrect saving of "running files" in workspaces.yml local state file
What the above commit does:
- Modifies the workspace data model in an isolated build task
- Saves the modifications in the isolated build task
The result is that as soon as two workspaces are building in parallel, only one of the modifications can possibly be taken into account after the builds complete, the second update of the running files will discard the modifications made by the first, or rather, since the main task never updates it's data model except for doing
Workspace.clear_running_files(), only one set of running files can ever be saved. For a session of
bst --on-error continue build ..., it will only ever be the last modification which is saved.
I noticed that
Workspace.clear_running_files() is also called in
Element._assemble_done(), which is called in both the isolated task and in the main process after a build completes; but this part is not problematic, because it only hits that code path from the frontend if
True, which only happens in the frontend, I thought this was done intentionally.
The solution to this is not to use lock files (there shalt be no
lock/reload workspace file/modify/save/unlock performed in the tasks), rather; the changes which a task desires to make to the
workspaces.yml must be sent back to the main process upon completion, such that the data model is maintained in the main process and writes are serialized there.