This would be super useful for us.

Can you walk me through this use case a bit? How many dependencies do tasks have in your system?

It's also a little surprising to me that this is listing things which are blocked by a task (right?) not things which are blocking a task. I could imagine wanting to know who owns all the stuff that's blocking a task so you can, e.g., go yell at them or whatever, but I'm less clear on why it's useful to see things which a task blocks.

We're using high-level tasks to manage individual development/release phases of features, similar to T1049: Implement Harbormaster or T2015: Implement Drydock but with many more subtasks (now called "Blocked By" tasks, it seems, but I'll continue to refer to them as subtasks in this comment for continuity). On the individual task page, you can see a list of all the subtasks of the item (sorted by open v. closed), but there is no mechanism to view those tasks by priority or by assignee, or anything else you can do via Advanced Search.

So the use looks like: Show me all subtasks of "Implement Drydock" grouped by assignee or Show me all subtasks of "Implement Harbormaster" grouped by priority. AFACT, there's no way to do that.

Given your comment and the recent naming changes, perhaps there should be two fields added to Maniphest search: Blocked By Task IDs and Blocking Task IDs, which would enable either view.

That makes sense -- either I'm misreading this or the edge type isn't right? Or maybe we're using the edge types wrong internally? See inline...

No, it's correct. We've got it running on our internal Phabricator installation. You want the list of all tasks that are dependended on by the task you're querying for. So if I wanted all subtasks of T1049: Implement Harbormaster, I would want all tasks that are dependended on by T1049, not all tasks that depend on that task.

Ohhh, it's querying on edge.dst. Another way to write the query would be:

JOIN edge ON edge.dst = task.phid WHERE edge.src IN (%Ls) ...

This would use the other half of the edge.

Since there a (src, type, dst) key but no (dst, type, src) key these approaches probably have very different query plans. I would expect the src join (as here) to require a table scan of the edge table, while the dst join would be able to use the key.

That seems to be the case in practice. Here's the query plan on this install for the query as written (table scan of the entire edge table):

mysql> explain SELECT * FROM maniphest_task t JOIN edge e ON e.src = t.phid WHERE e.type = 3 AND e.dst IN ('PHID-TASK-24ufnbymvb5hiahutw45');
+----+-------------+-------+--------+---------------+------+---------+-----------------------------+------+-------------+
| id | select_type | table | type   | possible_keys | key  | key_len | ref                         | rows | Extra       |
+----+-------------+-------+--------+---------------+------+---------+-----------------------------+------+-------------+
|  1 | SIMPLE      | e     | ALL    | PRIMARY,src   | NULL | NULL    | NULL                        | 4349 | Using where |
|  1 | SIMPLE      | t     | eq_ref | phid          | phid | 194     | phabricator_maniphest.e.src |    1 |             |
+----+-------------+-------+--------+---------------+------+---------+-----------------------------+------+-------------+
2 rows in set (0.00 sec)

Here's the query plan for the version which uses the key:

mysql> explain SELECT * FROM maniphest_task t JOIN edge e ON e.dst = t.phid WHERE e.type = 4 AND e.src IN ('PHID-TASK-24ufnbymvb5hiahutw45');
+----+-------------+-------+--------+---------------+---------+---------+-----------------------------+------+-------------+
| id | select_type | table | type   | possible_keys | key     | key_len | ref                         | rows | Extra       |
+----+-------------+-------+--------+---------------+---------+---------+-----------------------------+------+-------------+
|  1 | SIMPLE      | e     | ref    | PRIMARY,src   | PRIMARY | 198     | const,const                 |    1 | Using where |
|  1 | SIMPLE      | t     | eq_ref | phid          | phid    | 194     | phabricator_maniphest.e.dst |    1 |             |
+----+-------------+-------+--------+---------------+---------+---------+-----------------------------+------+-------------+
2 rows in set (0.00 sec)

Oh, great point. I wasn't aware of which indexes were available on the edge table. I'll definitely make that change. Anything else to include in the next diff? Should I rename/add Blocking Task IDs and Blocked By Task IDs as well?