Describe the bug
Currently, each worker process has its own sql connection with thread checking enabled (but connection shared beyond that). While this works most of the time, during the git update cycle a new thread is created, violating the same-thread constraint.
This needs to be fixed on two levels:
1) if an update fails, the git repo needs to be rolled back so it can be attempted again
2) The git update thread needs its own connection. (And in general database.py should probably be rewritten)
To Reproduce
Steps to reproduce the behavior:
Run in production mode
Induce a git update
Expected behavior
Git update to happen, regardless of failure
Describe the bug Currently, each worker process has its own sql connection with thread checking enabled (but connection shared beyond that). While this works most of the time, during the git update cycle a new thread is created, violating the same-thread constraint.
This needs to be fixed on two levels: 1) if an update fails, the git repo needs to be rolled back so it can be attempted again 2) The git update thread needs its own connection. (And in general database.py should probably be rewritten)
To Reproduce Steps to reproduce the behavior:
Expected behavior Git update to happen, regardless of failure