Specifically, if you put like a sleep(10) directly after applyPlan() I would expect that to trigger the race ~100% of the time as long as the queue isn't too full. You could see if the behavior is similar to the behavior you've observed.

Yeah, I think that can race. Here's an example -- open two connections to MySQL, mysql1> and mysql2>. In the first window do this:

I'm not sure I understand your math -- here's what I get:

Oh, you removed openTransaction(), so that's probably not the culprit.

It's vaguely possible that openTransaction() is the culprit. applyPlan() queues a daemon task, and I could imagine the race might be:

It sounds like this no longer reproduces for you.

• If the changes are relatively minor, add a bunch more #ifdefs? We already have some of this to deal with prior API changes, and I believe this approach is historically a standard one across other extensions.
  • If the changes are substantial, maybe we need to get more creative.

If you want to test that something in this vein works, I'm happy to bring it upstream.

We should be able to just omit the final argument if remote is not specified. We can refine that later, but our usage seems like it's in the wrong to me.

If a Phurl doesn't have a name, should we still show the empty name property on the object view?

No, that's not currently possible, but it might be worth filing a Maniphest task for that.

I can't immediately reproduce this. Here's what I did:

Oh sorry... I am dumb.

(Assuming you meant XHPAST rather than XHProf)

The default value of metamta.email-body-limit is 512KB. Does your server reject 512KB messages, or have you raised this limit, or do you expect 512KB messages to send cleanly?

cdda79e9 is not a commit in rARC or rPHU, and the last commit to libphutil was on 12 Nov (while that output shows a change on 13 Nov), and it's impossible for both libraries to have the same commit at HEAD. Is he running a forked version of arc with local modifications?

What version of arc does the user have (per arc version)?

If you have long-term local access to a user's machine and can install a keylogger, you can just steal the session cookie. Being able to establish a second session instead of stealing the first session cookie is not a meaningful escalation.

Maybe adding --trace will reveal what's going on?

We apply a Space constraint when executing this query and the object never makes it as far as the application. This is broadly by design, as it hugely improves the scalability of Spaces.

Your HTTP request should start a build, it should not wait for the build to complete. See:

Never mind, this was straightforward to reproduce:

This should be fixed at HEAD. Let us know if you run into anything else.

Do you have a stack trace in the error log offhand? I can't immediately reproduce this on this install after upgrading. I have a good idea what's going on, but if you have a stack handy that might be faster.

It looks like this database did exist as of D3659, but the name was mistaken (pushed as xhpast, should have been xhprof). It was renamed in D3670.

The Sendgrid v3 API does not currently include an API method for sending mail.

This install is just a little out of date, second issue should be fixed at HEAD.

I was able to reproduce this easily by following your instructions. We'll get this fixed. Thanks for the report!

Ah sorry, I thought Almanac wasn't a prototype but Drydock was. I was mistaken though.

On another note, why doesn't Almanac use Passphrase for key storage?

Why do you want completely separate installations? From your description, it sounds like you want Spaces instead. Spaces allows you to namespace different parts of Phabricator such that things within the Engineering namespace wouldn't necessarily be accessible to the HR namespace.

Fixed in rARC66ab1c955d27ff7875f62eb51a0bd6c4770a7ae3.