Idempotency
An idempotent request can be repeated without producing an additional business effect. Classify LCE operations by their semantics before retrying; the HTTP method alone is not sufficient.
Current contract
The common request field threadId is described as a tracking identifier. It must not be treated as an idempotency key unless a specific operation explicitly documents that behavior.
Classify before retrying
Read-only queries
A /query/... operation can be semantically read-only even when it uses POST. Retry only after confirming the operation does not change state.
Updates and deletes
The desired final state may already have been applied. Read the resource before repeating an uncertain request.
Creates and processes
Repeated creates, workflow actions, imports and external-provider calls can create duplicate effects.
Handle an uncertain outcome
try {
return await createResource(request);
} catch (error) {
if (!isUncertainTransportFailure(error)) throw error;
// Do not immediately repeat the create.
// Query by the stable business reference supported by this domain.
const existing = await findByExternalReference(request.externalReference);
if (existing) return existing;
// Retry only when the operation contract and project policy allow it.
throw new Error("Create outcome is uncertain; manual verification required.");
}The example illustrates a safe recovery pattern. The real lookup field and retry policy must come from the selected LCE domain.
Integration practices
- Assign a stable external business reference when the create model supports one.
- Persist the request reference before making a side-effecting call.
- After a timeout, query the resulting resource or workflow state before retrying.
- Serialize duplicate submissions from UI controls and message consumers.
- Store the LCE response and resulting resource ID with the originating command.
- Retry only transient failures and cap the total retry duration.
- Use operation-specific idempotency behavior if it is explicitly documented in the future.