An ERP agent timed out after the write. What should it do next?

Description and use

When an ERP agent times out after a write, the system cannot confirm success, risking duplicates. Tests showed recovery via authoritative read-back resolves uncertainty.

Problem

When an ERP agent times out after a write, the caller cannot determine if the write succeeded, leading to uncertainty and potential duplicate actions.

Outcome

The test demonstrated that unknown outcomes can be resolved through authoritative read-back, preventing duplicate writes and enabling safe recovery.

Workflow

• Record target environment, business object, operation, approved input revision and stable request identity before dispatch.
• Recheck target and authorization at execution; if input changed, obtain decision on changed request.
• After dispatch, classify outcome as confirmed, definite rejection, or unknown.
• For unknown outcomes, perform lookup using stable business reference or correlation method.
• Provide operator with original request, last known state, and evidence for investigation.
• If compensating action needed, give it its own identity and authorization and retain original result for later review.

Evidence

A timeout is a poor instruction to retry a business transaction. The receiver might have committed the change before the response disappeared.

Source

The timeout case made one fixture write, then raised an exception before returning its receipt. The controller retained an unknown outcome.

Source

Read-only reconciliation recovered the receipt and verification moved the case to its accepted state.

Source

For an unresolved outcome, give the operator the original request, last known state and evidence needed to investigate.

Source