What exactly does arc patch --trace D489 output?

I haven't looked at the code, but, to my understanding, the way arc patch Dx actually works (on git) is roughly:

1. Download Dx, (probably to a temp file.)
2. Parse its metadata, looking for a parent hash and a list of dependencies.
   • If you have Dx's parent hash in .git/objects, check that out as arcpatch-Dx. Apply Dx on top of that, and ignore any listed dependencies.
   • If you don't have it, then start pulling down dependencies.

So, you could run into this "unexpected" behavior if you develop Dx and Dy on two separate branches, both based on master, for instance, and then specify the dependency between two them using the web UI.

@staticshock I think I'm seeing the same thing, except not quite. I have a linear patch history, which I submitted to http://phabricator.freedesktop.org (open access) as D1 through D17 (not in any upstream repositories; only in my local tree and Differential). Each patch was created individually with arc diff, per rationale in T7076.

arc diff didn't seem to realise when submitting these patches that the dependencies exist: no dependency chain ever got added when submitting. Even when adding the dependency chain post-hoc through the web interface, 'arc patch' gets confused and fails to apply. Here's the output from --trace:

As you can see, it calls differential.query exactly 18 times, which makes me think it's traversing the dependency chain. However, it never tries to apply those patches: it instead surmises that the commit hashes for those patches aren't present in the tree, and asks what to do. Answering Y just applies D17 without applying any of the prerequisites.

You're more than welcome to play with the instance linked above, if it helps at all.