Pretty sure this is the same as T6076; I'm going to merge that here.

Yup, confirmed fixed. Thanks again y'all!

I dunno, taking a guess.

From IRC:

I think we also need a field on a lease to indicate that it's not a permanent lease, or it's a caching lease or something of that nature. Basically the host lease that the working copy has for it's cache shouldn't prevent the host resource from being closed if shouldCloseUnleasedResource returns true.

Ah, that was an intermediate error that I got when I was trying to solve it. I'll implement the fix that you have in D13335 and it solves the problem I experienced. :)

Hm, in your original report the stack trace doesn't mention DrydockConstants.

Ah, to recreate this you only need to add a build plan with a "Lease Host" step and you will get this fatal. The class referenced in the first message in the stack trace will be DrydockConstants and not PhabricatorWorkerArchiveTaskQuery though.

I don't believe there's a deadlock here. What happens is:

"Block and wait" can deadlock the queue and we're going to have to stop doing that if we're doing it anywhere.

"Block and wait" is what currently happens when you have more leases come through than maximum resources available (actually for blueprints that implement min-max-expiry it will optimize to only allocate as many resources as is really needed).

That situation is unavoidable. Here's a way we can hit it with pre-checks:

That sounds similar to the solution I proposed, but I'm not entirely sure that will work due to the health check running as a queued task (and preemptively preventing leases against suspicious resources I guess). I'm particularly concerned about this scenario:

First thought is to do this:

As chad advice me I would ask here.

If you have questions or needs with Drydock, best to place them in T2015 so they're not lost and around when implementation does happen.

https://secure.phabricator.com/book/phabricator/article/prototypes/