The error output was not from the script, it was just errors. I think I remember looking into this a long while ago and it's because the migrate script (incl dry run) actually reads all of the files. The act of reading the file is what generated the error. I should have described this a little better than "dry run shows some files are going to fail", and instead described it as "dry run shows errors for some of the files".

FWIW, we have a script that uses arc patch --nobranch to "graft" someone else's working tree into your own working tree. We suppressed arc patch output entirely after enough people complained about "all of the branches its making".

We can leave this at "reduced expected incidence rate to < 1/3k" and I'll come back here if it happens again if you don't have any more obvious ideas.

Oh I lied, checked the old logs, this error was present the last two times it occurred, but not present when it happened this evening.

This perfectly recreates the symptoms, except it generates an error in the daemon log:

DAO's prefixed CISubmitQueue are in their own database. There has never been any problems with referential integrity / never seen anything in the database that would indicate we'd written records incorrectly. But you may be right about the tasks being written before the plan is written. I suspect that would cause errors though, I can try to reproduce that first in order to rule out our specifics being the problem.

Let me post the whole block, it didn't seem relevant:

Yeah it's busted by default including newly created steps

if you have a many-minutes-long build process anyway maybe shaving startup time from 2 minutes to 2 seconds doesn't really matter

I did do at least this to try to get this to disappear:

I'll put them into rotation and report back on A/B results.

I replaced the existing logo with the one you provided some time ago. It has not been met with universal fanfare as I would have expected given the level of artistry displayed.

I thought Phabricator was an adventure game, that sounds an awful lot like RTS.

"out of the box" support would look something like: if you triggered the action that created this build, only you have control over stopping it (or admins). If an application started the build (eg, global herald rule in response to a commit), only admins have control.

We're already waist deep into modifying DB records in Harbormaster that we probably shouldn't be, any expanded control over policies there at all should enable our other custom apps to make it do what we like.

I'm ~1 week away from actually having our ducks in a row so we can merge upstream, would expect to land this right about then. Not sure if workboard implies some kind of scheduling?

Yeah it works for us to just kill it in arc unit for now, we're stuck a few weeks behind master for the time being so an upstream fix wouldn't help us immediately anyways.

So I guess yes? You're saying implement this in the test engine?

We have our own build step which just runs arc unit --everything --coverage --ugly in a working copy and then deals with the exit code and json returned.

No you're correct and I'm getting what you're saying now.

Anyways, tl;dr; that column is useful to us.

I have a bad habit of quickly reading things and responding without exactly comprehending what's been written, you didn't say what I thought you said about the coverage totals.

I agree with you philosophically, I think that coverage is mainly a heuristic we use to determine whether you're entering an area of the codebase that has been "well cared for". For us, typically, if you pull up a subproject in one of our repositories and there is no coverage, you will probably treat everything in there with extreme distrust. Actual coverage percentages don't matter to us so much.

I'm going to use Evan's, but thanks @chad.

Do you plan on incorporating a coverage column in the UI? I have actually already created a "coverage" application which rolls up coverage information per directory and shows us that info, which is how I surfaced this bug.

I'm a few weeks behind master on this install if that's relevant, I can't see any commits between then and now which would fix this, but here are the hashes I'm at:

DrydockBlueprintImplementation::newResourceTemplate can't possibly work because it calls a nonexistent mutator on DrydockResource. By extension, the entire DrydockWorkingCopyBlueprintImplementation is currently unusable.

Should be DrydockBlueprintImplementation::executeAcquireLease

I set up testing machines to prove out new features to the non-dev users we have. They complain it's broken.

Thanks. It's not too burdensome for me to just add a big block of text to our exceptions in the case of failure letting our users know what they should probably do. But the state you get put in after a failed land is pretty bad in some cases, especially if you are unfamiliar with arcanist.