IF last trap action THEN

Runs the ops nested underneath it when the last trapped error in this job was answered with Skip, or with Retry, whichever you pick. It gives a rule a way to behave differently on a second attempt, or to clean up after a step that somebody waved through.

It only means anything in a job where an op has Error Handling set to Trap Errors on its Options tab. That setting is what stops the job and asks a person what to do. With Throw Errors or Ignore Errors nothing is ever recorded and this op never fires. The monitor side of that conversation is described in Monitoring Jobs.

Fields

Job Last Trap Action

A choice of two, Skip or Retry. It arrives set to Skip. The block runs when the recorded answer matches exactly.

There is no third option and no wildcard. To react to any trap regardless of the answer, put two of these ops side by side, or test the variable _last_trap_action with NOT EMPTY in IF var condition THEN.

The value is a fixed choice, not a text field, so nothing in it is variable-expanded.

When the answer is recorded

A trapped job offers four responses. Only two of them leave anything behind for this op:

Answer	Effect on the job	What this op sees
Retry	the trapping op runs again from the start, nested ops included	Retry
Skip	the rest of the trapping op is abandoned, the rule continues after it	Skip
Abort	the step fails for real	nothing, the job is over
Pause	the job keeps waiting for a later answer	nothing yet

The answer is written before the retry begins, so a second pass through the trapping op already sees Retry.

Nobody has to be watching. When the trapping op has a Trap timeout (seconds) above zero, the Trap timeout action is applied on its own once the countdown runs out, and a timeout action of Skip or Retry records the answer exactly as a person would. Answering Pause suspends that countdown rather than resetting it, so a paused job waits indefinitely and nothing is recorded until somebody answers again.

Trap max retry (0 means unlimited) caps how many times Retry is honoured on that op. Once the allowance is spent, the next error there fails the job outright instead of asking again, so a rule that tests for Retry stops seeing new answers at that point. The cap is read off the same recorded answer this op tests, so clearing the flag inside the retried block resets the cap as well and the job goes back to asking.

During the rollback pass, trapping depends on Trap in Rollback? on the trapping op. With that unchecked, errors in rollback abort instead of trapping, so no answer is recorded and this op does not fire.

The flag is sticky

Nothing clears the recorded answer. It stays in the stash for the remainder of the job and carries into the following job steps, so an IF last trap action THEN placed in POST will happily fire on an answer somebody gave back in PRE. Clear it with DELETE last trap action as soon as you have acted on it.

An unset flag matches neither value, so before the first trap of the job the block is skipped whichever option you chose. There is no "nothing happened" setting. Use ELSE for that branch.

Where to put the op

Inside the trapped block, an answer of Retry means the block runs again from the top, so a test for Retry placed there fires on the second pass and every pass after it. That is the way to make the second attempt take a different route.

An answer of Skip abandons the rest of the trapped block, so an op placed after the failure point inside that block never runs. A Skip test has to sit after the block, not inside it.

Being a branch, this op hides most of the Options tab. Enabled and Debug Mode are all that remain there, and the rollback, parallel, timeout, semaphore and error-handling settings are gone, so the op cannot trap errors of its own. ELSE and ELSIF condition THEN may follow it if they sit immediately after it.

Combining with other ops

DELETE last trap action resets the flag so the next test reads a fresh answer rather than an old one.

LOG Message inside the block leaves a trail explaining why the rule took the path it took. The answer itself is already in the job log, recorded as a warning naming the action, the user who gave it and their comment.

FAIL under a Skip test turns a skipped step into a hard stop later on, when the work that was skipped was not really optional.

IF ROLLBACK pairs with it when the recovery you want differs between the forward and rollback passes.

Examples

Take a different route on a retry, placed inside the block that traps.

Job Last Trap Action: Retry
  LOG Message                Second attempt, using the fallback host
  SET VAR                    target_host = foo_backup

Clean up after somebody waved a failing step through, placed after that block.

Job Last Trap Action: Skip
  LOG Message                Deploy step was skipped by an operator
  Change Topic Status        topic to Needs Review
  DELETE last trap action

Stop the job later on if the skipped step was load-bearing.

Job Last Trap Action: Skip
  FAIL                       The deploy step was skipped, the release cannot be certified.