Gates

ConfigHub blocks particular kinds of actions in two different ways. Validation Errors are recorded by ConfigHub itself when a validating trigger does not pass, and block publishing a Release. Destroy Gates and Delete Gates are metadata you set by hand to block destroying or deleting something. There are also non-blocking Validation Warnings.

Validation Errors are set by ConfigHub automatically when validating triggers do not pass on the most recent configuration data revision for a unit. They block publishing a Release that would bundle that revision, until the underlying issue causing the validation failure is addressed.

Two details are worth knowing:

• They are checked against the revision being bundled, not only the unit's head revision. So cub release publish --revision <tag> evaluates the errors on the tagged revisions specifically.
• A blocked publish is not terminal. The check re-runs the unit's triggers as it evaluates them, so once the underlying problem is fixed, publishing again succeeds.

These were called Apply Gates until the field was renamed to ValidationErrors — the old name predated the release model, from when configuration was pushed to a target rather than published. ApplyGates and ApplyWarnings are still returned by the API as deprecated read-only copies of ValidationErrors and ValidationWarnings, and still work in --where, --select, --columns and order_by, so nothing written against the old names has to change yet.

Validation Warnings work similarly to Validation Errors but are non-blocking. They are produced by validating triggers that have Warn set to true. When a trigger's validating function fails and the trigger is in warn mode, the failure is recorded as a Validation Warning rather than a Validation Error. Validation Warnings are visible in the UI and CLI but do not prevent a Release from being published. This is useful for advisory policies, soft constraints, or gradual policy rollouts where you want to surface issues without blocking deployments.

Both Validation Errors and Validation Warnings use a 3-part name format: <space-slug>/<trigger-slug>/<function-name>, naming the trigger that produced the error or warning as it was when the error or warning was recorded. When a trigger references an Invocation with several functions, each function gets its own error or warning, and its name carries the function's position in the Invocation, counting from 1: platform/checks/vet-celexpr:2. The unit also records the ID of the trigger behind each name, in ValidationTriggerIDs, so the trigger can still be found after it is renamed or moved; the names themselves are updated the next time the unit's triggers run. Detailed validation results (failure messages and details) are also stored alongside them. Triggers can include a Description field that explains what the trigger checks and how to fix failures; this is shown in the UI when hovering over one.

A special temporary entry, awaiting/triggers, is set when configuration data changes. It indicates that triggers have been enqueued for asynchronous evaluation and is automatically removed when all triggers complete. Many CLI commands support --wait to poll until it clears.

Validation Errors can also be produced when the Worker an external function is served through is disconnected and unable to execute a trigger's function. In this case, validating and mutating triggers for the unavailable worker produce errors, reflecting that the check could not be performed. See the validation and policies guide for details on worker disconnection behavior and the FailOpenAfter field.

Destroy Gates are metadata properties that can be explicitly set on units. The string associated with a Destroy Gate is intended to convey the reason that destruction is blocked and/or the stakeholder or component blocking it. A Destroy Gate on any unit in a Release's bundle blocks withdrawing that Release. Currently anyone with permission to edit an entity may add or remove any destroy gates.

Delete Gates are metadata properties that can be set explicitly on any entity in ConfigHub. The string associated with a Delete Gate is intended to convey the reason that delete operations are blocked and/or the stakeholder or component blocking the deletion. Currently anyone with permission to edit an entity may add or remove any delete gates.

A Delete Gate on an entity residing in a space blocks deleting the space with --recursive. --recursive-force deletes the space and everything within it regardless of their gates, based on the principle that tenants within a space should not necessarily have the power to control the fate of the whole space. A Delete Gate on the space itself blocks both, so to protect the entities within a space, place a Delete Gate on the space as well. Delete Gates are separate from what other entities reference: see deleting referenced entities.