While not required, this would be materially helpful on the instance management console, so queued operations could be made visible.

T5166 is another attack on this -- which is more powerful in general, but not necessary for the Phacility use case, since viewing tasks by object would be sufficient.

Rough attack on this would be:

• Allow PhabricatorWorker::scheduleTask() to take an objectPHID (maybe turn priority into array options?)
• Write it to phabricator_worker.worker_activetask.
• Make sure it migrates cleanly to worker_archivetask (it should by default if you add the column to the parent DAO).
• Add a key for it.
• Allow PhabricatorWorkerLeaseQuery to withObjectPHIDs().
• (It would also be nice to write a PhabricatorWorkerArchiveTaskQuery which would just be a vanilla query class, then use it in places where we do a raw load, for general cleanliness.)
• Maybe pass this for some existing tasks, but we can do this as necessary.

This would allow the instance console to easily show pending tasks for an instance, and give us more immediate feedback about queued actions. With an ArchiveTaskQuery, we could also easily show recently completed tasks and get some logging for free.

Some early notes and questions looking at this -

There's an assumption that each task maps to exactly one object that has a PHID. This is tricky in the MetaMTA case for the shipped mail and the unshippsed sms workers. For mail, the worker task is scheduled as a by-product of saving the phid-less PhabricatorMetaMTAMail, and thus not easily mapped to an object phid.

Question - do you want either 1) there to be no objectPHID recorded for the MetaMTAMail case or 2) the code augmented such that the "real object PHID" (e.g. a task getting updated triggering mail; the task is the "real object") gets passed through and recorded?

PhabricatorWorker::scheduleTask and PhabricatorWorker->queueTask both need augmentation. The latter will require checking out PhabricatorWorker->getQueuedTasks callsites and making sure they handle the data correctly.

No object PHID is 100% fine for now. In the very long run it would be nice to get the "real" object PHID (e.g., the original task or whatever that the user commented on), but for now I just need the slot to put Phacility instance PHIDs in so I can show them on the console. It's fine if core/upstream support is spotty/limited/imaginary.

Sounds good, thanks!

I'm going to kick this out of Phacility, we've got everything we need now.