We have a single method to update workspace builds that covers multiple fields. Typical use in our codebase is, in a transaction

1. Read the workspace build
2. Update the workspace build, using the values from 1 for any field we are not changing.

At the default transaction isolation, this is not safe. If another database user commits changes to the same build between 1 and 2, the transaction completes successfully and we clobber those changes.

Solution Notes

In addition to fixing our updates to be safe for concurrent use, we should consider splitting the provisioner_state column into pre-build state and post-build state. With state overwriting state, it can be hard to diagnose why a build acted the way it did. This wouldn't have saved us in this case, but would have made diagnosis easier.

cc @mafredri @johnstcn @matifali @bpmct