Homec4science

Fix an issue where Drydock followup tasks would not queue if the main task…

Authored by epriestley <git@epriestley.com> on Dec 18 2015, 15:38.

Description

Fix an issue where Drydock followup tasks would not queue if the main task failed

Summary:
Ref T9994. This fixes the first issue discussed on that task, which is that when a merge fails after "arc land", we would not clean up all the leases properly.

Specifically, when a merge fails, we use queueTask() to schedule a followup task. This followup destroys the lease and frees the underlying resource.

However, the default behavior of queueTask() is to not queue tasks if the parent task fails. This is a reasonable, safe behavior that was originally introduced in D8774, where it kept us from sending too much mail if a task did "send some mail" and then failed a little later on and got retried.

Since I think the default behavior is correct, I just special cased the behavior for Drydock to make it queue even on failure. These are the only types of followup tasks we currently want to queue on main task failure.

(It's possible that future Blueprints might want some kind of more specialized behavior, where some tasks queue only on success, but we can cross that bridge when we come to it.)

Test Plan:

  • See T9994#149878 for test case setup.
  • I ran that test case again with this patch, and saw the followup task queue properly in the --trace log, a correspoinding update task show up in /daemon/, and the lease get destroyed when I ran it a moment later.

{F1029915}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9994

Differential Revision: https://secure.phabricator.com/D14818

Details

Committed
epriestley <git@epriestley.com>Dec 18 2015, 17:17
Pushed
aubortJan 31 2017, 17:16
Parents
rPH5bbf0ba13256: Add a setup warning about deprecated Maniphest policy configuration
Branches
Unknown
Tags
Unknown

Event Timeline

epriestley <git@epriestley.com> committed rPHe9af4f897079: Fix an issue where Drydock followup tasks would not queue if the main task… (authored by epriestley <git@epriestley.com>).Dec 18 2015, 17:17