You essentially only need the revision IDs in the response, right?

I can give you a good-enough version of this with that information pretty easily. Fleshing it out in the longer run may take more thought/work but the basic skeleton is straightforward.

The only reason not to do this is that it will make it slightly harder for us to move arc to differential.revision.search in the future because we'll likely need to both detect its existence and detect that it has all the stuff we later add so that arc has everything it needs. However, that's not particularly difficult and not a meaningful reason to hold this.

Actually, this is slightly more involved because you want to select open revisions.

Currently, revision status is stored internally as an integer constant, and implemented in the SearchEngine as a dropdown of hard-codes which expands into internal integer constants. These approaches are both outdated and API-hostile: we'd rather give callers meaningful constants like "open" as an API than meaningless integers like "2", and the dropdown-into-hardcodes makes selecting certain state filters impossible.

Until that is cleaned up, you may be able to execute a custom query for "open" revisions, grab the key from the URI, provide that as a the "queryKey", layer your project constraints on top of that, and get the desired results. We can fix this more broadly but it will take more work, bleeds into arc changes, and gets tangled with possible new states in T2543.

Anyway, let me know what you need beyond what D16089 provides and we can figure out how to move forward. I'll push it here in a minute if you want to poke at it.

Awesome, thanks for the quick turnaround. This looks good to me. Currently I'm using revision ID, title, status, and authorPHID in the response for display purposes. I'll try your recommendation for 'open' revisions using the queryKey to handle the status.

I return the other fields, but don't currently return "status" because I'd have to return an internal numeric constant. So we may need to fix that more thoroughly before you can move forward.

(As a real gross workaround you may be able to make several queries, one for each status, then infer the status based on which query you executed. This will be slow/horrible, though.)

I was able to filter by status using the queryKey, which is much more valuable than displaying the status. So omitting status from the response is ok by me considering the level of effort required to refactor the numeric constants. Thanks again, much appreciated!