Page MenuHomePhabricator

Give "bin/worker" flags to repeat and retry tasks
ClosedPublic

Authored by epriestley on Mar 5 2019, 1:36 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 14, 3:22 AM
Unknown Object (File)
Sun, Nov 10, 5:19 AM
Unknown Object (File)
Sun, Nov 10, 2:09 AM
Unknown Object (File)
Sun, Nov 10, 1:55 AM
Unknown Object (File)
Sun, Nov 10, 1:47 AM
Unknown Object (File)
Sun, Nov 10, 1:33 AM
Unknown Object (File)
Sun, Nov 10, 1:08 AM
Unknown Object (File)
Sun, Nov 10, 12:17 AM
Subscribers
None

Details

Summary

See PHI1063. See PHI1114. Ref T13253. Currently, you can't bin/worker execute an archived task and can't bin/worker retry a successful task.

Although it's good not to do these things by default (particularly, retrying a successful task will double its effects), there are plenty of cases where you want to re-run something for testing/development/debugging and don't care that the effect will repeat (you're in a dev environment, the effect doesn't matter, etc).

Test Plan

Ran bin/worker execute/retry against archived/successful tasks. Got prompted to add more flags, then got re-execution.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

amckinley added inline comments.
src/infrastructure/daemon/workers/management/PhabricatorWorkerManagementExecuteWorkflow.php
71

I was actually playing around with this while writing D20200. I wanted to unarchive a task and also run it in the foreground with PhabricatorWorker::setRunAllTasksInProcess(true), but that doesn't work since unarchiveTask assumes there are real daemons running somewhere to pull it out of the queue. Is there any way to give the execute and retry flows a --foreground flag?

src/infrastructure/daemon/workers/management/PhabricatorWorkerManagementRetryWorkflow.php
19

Would "Repeat tasks which already successfully completed" be clearer/more consistent?

45–53

Did you already try this with the >> bit left-aligned with the first green column? As-is this still looks a little weird to me.

49

"not be repeated"

This revision is now accepted and ready to land.Mar 5 2019, 6:36 PM

The execute workflow is always foreground, so execute --id ... --retry is now "foreground retry", and execute --id ... --retry --repeat is "foreground retry, repeating if necessary".

  • Clarify help/guidance around "repeat" vs "retry" flags.
  • (Agreed on the ">>", I'll see about touching that up a little.)
This revision was automatically updated to reflect the committed changes.