Single-Flight and Idempotency: Protecting Against Repeat Actions
Two controls address different risks: overlapping work on one record and retries of the same operation.
A timeout does not tell you whether a change succeeded. A second request does not tell you whether it is new work. Those are execution problems, and asking the model to “be careful” does not resolve them.
Fibric uses single-flight and idempotency in its governed execution path. They address different risks: concurrent work on the same entity and repeated attempts at the same operation.
Single-flight coordinates overlapping work
Single-flight gives execution one owner for an entity at a time. Another attempt on the same entity cannot simply start an independent competing execution while the first owns it.
That matters when two requests concern the same work item. Both can be sensible in isolation while creating a conflict if they run together. Serializing execution gives the system a boundary at which to check the current state.
Single-flight alone does not establish that two differently described plans are the same business action. The workflow still needs correct entity identities and state checks.
Idempotency identifies a repeat
An idempotency key identifies an operation so the executor can recognize a retry. A repeated key can return the recorded result instead of starting another execution.
The key must represent the same operation consistently. Two requests with different keys are not automatically duplicates. The connector’s behavior and the external system’s confirmation also matter when an effect crosses system boundaries.
| Risk | Control to inspect |
|---|---|
| Two executions overlap on one entity | Single-flight ownership |
| A retry repeats the same operation | Idempotency key and recorded result |
| The external system times out | Connector behavior and effect confirmation |
| Two plans describe the same business change differently | Entity mapping, state checks, and workflow policy |
Read the result before retrying blindly
An execution record helps establish whether the operation succeeded, failed, or remains unresolved. A retry should use the same operation identity where appropriate, rather than quietly becoming a new action.
For money movement or customer messages, the workflow needs the external system’s supported safeguards and confirmation. A kernel execution record alone cannot guarantee an effect in every external system under every failure condition.
Where BearScope fits
BearScope uses Fibric for supported governed actions. Single-flight and idempotency protect that execution path; they do not establish universal refund, replacement, or messaging capabilities in the product.
See the security controls or book a demo to inspect the operation identity, result record, and connector requirements for one supported action.
See the work in BearScope.
Choose a workflow. We’ll demonstrate the current views, review your sources, and agree what a pilot should measure.
Book a walkthrough →