Skip to content
The Data EngineeringThe Data EngineeringBeta
About
Main content

Human-in-the-loop steps

Why must an approval wait be a durable row with a timeout and a default?

A human introduces an actor with properties that nothing else in the layer has: unbounded latency, no semantics and non-idempotent actions. Approving twice is not the same as approving once, and the second approval may come from a different person. Three consequences follow.

The wait cannot hold a resource

A worker slot held for three days while waiting for a manager is the sensor problem at its extreme. At this length it is not about efficiency. The process will be killed by a deployment, a node rotation or a cluster upgrade long before the human answers. The wait must be durable and passive: a row in a database, not a process. That is why handles approvals naturally and a task-based handles them badly.

Every wait needs a timeout and a default

The default choice is again versus :

  • Fail-closed: deny on timeout. Safe, but it blocks the business.
  • Fail-open: proceed on timeout. Dangerous, and if you were willing to proceed anyway, the approval was theater. Choosing reveals that the gate had no teeth, which is useful information.

The record becomes evidence

Approvals are usually there for audit and compliance. Who approved, when, and on which version of the request must be recorded durably and immutably. The has become a system of record. This raises its retention and integrity requirements above those of a and brings audit-trail concerns into it.

The hidden cost

The cost that appears on no diagram: a human step sets the 's latency floor at human response time, and it is the one component whose latency distribution has a fat tail measured in days. If anything downstream has an , the human step has consumed the whole budget.

A human is an unbounded-latency, non-idempotent actor, so the wait must be a durable row rather than a held process, and the timeout default reveals whether the gate was real.