The design for the machine-aided depicts confirmation UI calls for images uploaded by the current user to be in a special section of their own. This means that in addition to the general, QueryPage powered suggestions feed, we need to be able to query for images that were uploaded by the current user with depicts suggestions needing review.
One option is to just query images by the user (uploaded after extension deployment date), and assume it will be a manageable amount and you can filter it for depicts on the client side. Another is to duplicate userid into the depicts table so it can be used for efficient filtering (but then you'll need a dedicated API). A third is to drop the QueryPage (its main use would have been a cheap way of providing a server-side frontend anyway, and there are no plans to use that) and use CirrusSearch (paired with some kind of locking mechanism if multiple users conflicting on the same image is a concern). That's probably the most sensible thing to do in the long run, except it's unclear whether there's a long run in this project.
For the prototype, I'd just go with the first. All the others require a custom API.
@Tgr Thanks! I actually ended up going with a new dedicated API list module, since usage of these things tends to be driven by a small number of very highly motivated users; I wouldn't want to have to trust in users having a manageable number of uploads.
CirrusSearch, on the other hand, doesn't seem like a justifiable investment of effort just yet. Also, I'm not sure if I've mentioned it in this context, but from my earlier experience using CirrusSearch in WikimediaEditorTasks, it seems to involve a pretty nontrivial startup cost; response times when querying CirrusSearch for candidates were around 2 seconds. That was the main reason the Android team ultimately rejected an API using that approach for their suggested microcontribution APIs.