I just tested and indeed @joshuaspence's steps are reproducible on https://phabricator.wikimedia.org

The immediate issue now appears fixed and it seems likely that the root cause is also fixed. We should still hunt down the bad cache behavior in the presence of wonky permissions.

This cropped up again and the permissions error also resurfaced, even though I previously nuked the directory.

In T13208#242142, @epriestley wrote:

To reproduce this issue, just need to Click on Default Column -> View as Query then leaving without Saving the query.

These reproduction steps don't work for me, and don't make sense given how the software works. If you believe you have a set of reproduction steps, can you walk through them step-by-step in more detail so I can reproduce the issue?

If anyone can come up with reproduction steps which actually work, this will probably take me about 3 minutes to fix. The only thing blocking this is that I have no idea how to reproduce it.

Fantastic, thanks very much @epriestley! I had indeed intended to take care of this myself was on other work this and last week and planned to come back to this. It also would have taken me much longer to realize that drydock.lease.search wasn't yet upstream and how to proceed from there, so I'm glad to see you were able to handle this so easily!

To reproduce this issue, just need to Click on Default Column -> View as Query then leaving without Saving the query.

I just a way to fix this. After using "/query/all" to get in the board. We can click on the "All Tasks" Filter -> "Save as Default" and we don't get issue 404 anymore.

To reproduce this issue, just need to Click on Default Column -> View as Query then leaving without Saving the query.
Workaround: add "/query/all" at the end of the url also work fine.
I am still reviewing the database to to set back to the buitin query

In T13208#242133, @20after4 wrote:

@dlgiang: if you go to maniphest and choose any of the existing saved queries, you will find the ID in the resulting url.

@dlgiang: if you go to maniphest and choose any of the existing saved queries, you will find the ID in the resulting url.

In T13208#242106, @aklapper wrote:

@dlgiang: T13208#241682 above links to https://phabricator.wikimedia.org/T199207#4413718 describing a workaround

@dlgiang: T13208#241682 above links to https://phabricator.wikimedia.org/T199207#4413718 describing a workaround

Are there any workaround for this issue ?

See PHI916. T11908 should move forward to the "migrate 700 callsites" stage, at least.

See PHI755, which could use verification around WorkingCopy blueprint selection.

D19762 adds a "supplemental allocation" behavior, which basically lets blueprints say "I want to grow the pool instead of allowing this otherwise valid lease acquisition".

After that, both hosts will have resources and jobs will allocate randomly, which should be good enough.

I believe you can work around this today by disabling the binding to host "A" in Almanac, running one job (which will be forced to allocate on host "B"), then re-enabling the binding. After that, both hosts will have resources and jobs will allocate randomly, which should be good enough. This is exceptionally cumbersome and ridiculous, of course (and it's possible that it doesn't even work).

A specific subcase here is when the binding to an Almanac host has been disabled. We should possibly test this during Interface construction, treat it as a failure, then recover from it.

Some of this touches Drydock but I'm just kicking it off the board since this mostly turned into a Harbormaster task.

I believe D16594 should implement this, one way or another, unless I'm misunderstanding the request.

Complicating this: there is no drydock.lease.search call upstream. So you're probably running some variation of D16594? But that already has ownerPHIDs.

goodbye pup

See PHI943. We should verify the modern behavior of PhabricatorGlobalLock in the presence of KILL <id> on the GET_LOCK() connection. I believe it is clear and explicit after D19702, which made the catch (...) more narrowly scoped.

My theory on the Drydock behavior is that we're getting into an "A, A, A" state. A lease comes in that needs a "B", so it releases a resource.

Next, I hit T13179 again. Yeesh. I rebased on my local hack-around for now.

From previous work, I already have functional Host and Working Copy blueprints locally so I'm likely punting on the Hoax/EC2 issue.

I'm happy to make these changes myself, or you mentioned wanting to contribute a patch?

I'm hoping to do a relatively small iteration here. The primary goal is to investigate PHI570, which reports some sketchy behavior. I generally want to unblock adopters of Drydock and fix critical weirdness but avoid improving it too much (i.e., avoid a real iteration on T13073) until we can clear other stuff out of the queue.

See PHI942 (internal) and PHI892 (internal).

Well, this sucks... But thank you for taking the time to explain the situation 😃

It's "open" in the sense of Apache-licensed and (mostly) developed in public (e.g., the information on this install is public rather than hidden behind a corporate veil).

@epriestley Does this mean that phabricator isn't open to contributions?

See Planning.

@epriestley
Support for PHPUnit 5.x ended on February 2, 2018.
We need this patch for PHPUnit 6/7 ... any idea when it can be landed on master?

Plus: db018.phacility.net, repo001.phacility.net, db024.phacility.net.

One more of these just came in for repo003.

I never remember the name of this ticket, so here are the things I think it's called: phone home mothership