Age | Commit message (Collapse) | Author |
|
afaict holding the lock over an await point gives tokio an opportunity
to run a different task - perhaps a different API request that would try
acquring the db connection lock. then it deadlocks; the second task
holds the thread hostage while waiting for the first task to release its
lock, which it can't do due to no thread being available for it to run
on.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
they are provided
|
|
going to more substantially extend this in .. a bit
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
should track this as something to retry later? maybe later
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
blocking task
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
some more refinements to how builds are run as well: build state discusses if a build us running, where the result is either a pass or fail
this is useful for deciding if a build is in progress and how artifacts (if any) should be presented
|
|
what happens if there are multiple jobs for the same commit? nothing good, really!
|