DELETE hashkey

Removes one key from the stash so that the rest of the rule behaves as though it had never been set. Use it to retire a flag once its branch is done, or to clear a value a loop leaves behind between passes.

Setting a key to an empty string with SET VAR looks similar and is not the same thing. An emptied key still exists, so ${name} expands to nothing and a NOT EMPTY test is false. A deleted key is gone, and ${name} stops resolving at all, which leaves the placeholder sitting in the text wherever it was used.

Fields

This op has no config form. Its Config tab is a data editor holding one entry, key, with an empty value.

key

A bare stash key name. Nothing about it is interpreted.

Placeholders are not expanded, so typing ${target} removes a key literally named ${target}, which almost certainly does not exist. Dots are not paths, so topic.title removes a flat key of that exact name if one exists and cannot reach inside a loaded topic to remove a nested field. The name is fixed at design time, so a key whose name is only known at run time cannot be removed here.

One op removes one key. To clear three values, drop three copies.

Removing a key that is not there is not an error. The op succeeds, the rule carries on, and nothing appears in the log, which makes a typo in this field completely silent: you believe a value is gone, later ops keep reading it, and the branch you expected to close stays open.

Leaving key blank removes a key with an empty name, which is to say nothing at all.

After the key is gone

IS EMPTY in IF var condition THEN is true for that name and NOT EMPTY is false, the same answers the name gave before anything ever set it.

${name} in a field that expands placeholders no longer resolves, and the literal characters ${name} are left in the text. A command line built from a deleted key gets ${name} in it rather than an empty gap. Where that matters, write ${nvl(name,none)} at the point of use, which substitutes none when the key is missing.

PUSH VAR starts a fresh list on its next run, because it creates the key when it finds none.

Nothing about the deletion reaches the job log. The op still shows in the log as a step of its own, under the name on its Config tab, so name the node after the key it clears.

Scope

The removal applies to the rule's working copy of the stash for the rest of the run, and to any rule reached from that point through CALL rule, which is handed the same stash rather than a copy.

Inside a STASH LOCAL block the rule works on a copy, so a delete made in there is discarded when the block closes and the key comes back.

You never need this op for a loop's own item variable. FOREACH file/item and FOREACH CI scope that variable to the pass and restore whatever it held before the loop started.

Rollback

A job that fails runs the same rule a second time with the rollback flag set, and that second pass starts from the stash the forward pass ended with. A key deleted going forward is therefore already missing when rollback begins.

Clearing Run Rollback on this node stops the second deletion. It does not bring the value back. If a rollback op needs a value that a forward op deletes, copy it into a second key with SET VAR before the delete and read the copy during rollback.

Combining with other ops

Pair it with SET VAR around a conditional block: set a flag, branch on it with IF var condition THEN, delete it once the block closes so that a later branch cannot pick up a stale answer.

Inside FOREACH file/item or FOREACH CI, put the delete at the top of the body. A delete at the bottom only runs on passes that reach the bottom, and a pass that branches around it hands the previous value to the pass after it.

To bring several values into the stash in one go rather than managing them key by key, see MERGE value INTO stash.

Examples

Clear a one-shot flag after the branch that consumed it.

key: needs_approval

Drop a large loaded structure once the rule is finished with it, to keep the stash small for the rest of the job.

key: file_index