DELETE last trap action

Removes the record of how the last trapped error in this job was answered. One line in the rule, no configuration, no output. Its reason to exist is that the record is otherwise carried for the rest of the job, so without this op every later test of it keeps matching an answer somebody gave much earlier.

Use it immediately after you have acted on a trap answer with IF last trap action THEN. That op explains where the record comes from and what the two possible answers mean.

Fields

None. The op has no config form, and its Config tab shows an empty data editor. It takes no argument, has no default to get wrong and holds no nested ops.

What it does

The stash entry _last_trap_action is removed. Nothing else in the stash is touched, the job status does not change, and _last_error is left alone.

Running it when nothing has been trapped is harmless. There is no error, no warning and no log entry. Dropping it into a rule as a precaution costs nothing.

The op appears in the job log as a step of its own, under the name on its Config tab. Name it after the reason the record is being cleared, because the entry is the only trace the op leaves.

Outside a job there is nothing to clear. A trapped error only pauses for an operator answer when the rule runs as a job; in a form rule, an event rule or a web service rule the failure is written to the log and the rule carries on, and no record is ever written. This op is a no-op there.

How long the record lasts

The stash is saved at the end of each job step and reloaded at the start of the next one, so an answer given during PRE is still readable during RUN and again during POST. A failed job also runs its rule a second time with the rollback flag set, starting from the stash the forward pass ended with, so the answer is readable there too.

That is what makes the record awkward. IF last trap action THEN cannot tell an answer given a moment ago from one given two steps back, and this op is the only way to draw the line.

Clearing inside a trapped block

The ceiling set by Trap max retry (0 means unlimited) on a trapping op is only enforced while the recorded answer still reads Retry. Clearing the record from inside a block whose Error Handling is set to Trap Errors therefore disarms that ceiling: the next failure traps again, the operator answers Retry again, and the count that was supposed to stop the loop is never consulted. If you clear the record inside a trapped block, do it deliberately and expect the block to be retryable without limit.

Outside the trapped block, clearing is safe and is what you normally want.

Combining with other ops

IF last trap action THEN is the op this one exists to serve. Read the answer, act on it, clear it.

DELETE hashkey does the same for any other stash entry, including _last_error left behind by a CATCH statement, which lasts just as long.

LOG Message next to it keeps the job readable, since this op says nothing about itself beyond its name.

Example

Handle the skip once, then forget it so that a later step starts clean.

IF last trap action THEN
  Job Last Trap Action: Skip
    LOG Message              Deploy was skipped by an operator
    SET VAR                  deploy_skipped = 1
    DELETE last trap action