Integration contract evaluation: duplicate fulfillment after a crash

A small failure with a large consequence

The worker sends a synthetic order to a local mock fulfillment provider. The provider accepts it. Before the worker records completion, its process is terminated. The same event is delivered again after restart. A repair must finish legitimate orders while avoiding a second fulfillment of the original order.

1. Fulfillment provider accepts the order.
2. The worker process stops before completion is recorded.
3. The event is delivered to a new worker process.
4. The evaluation checks the provider’s independent state.

Duplicate identity is the event ID. A different event ID is a separate request, even when the order reference is reused. A passing local test alone is easy to produce. The useful question is whether the business invariant survives interruption: replaying the same event produces one fulfillment, and other valid events are not discarded.

What this prototype includes

• One original synthetic duplicate-fulfillment scenario.
• A .NET console worker and an independent local Python mock provider.
• A deliberately broken implementation, a reference repair and intentionally incomplete variants.
• Behavioral checks covering process restart, redelivery and conflicting event payloads.
• Reproducible local instructions and recorded verification evidence.

The local verification suite exercised six behaviors across eight policy variants. The reference repair passed all six checks; the broken baseline and six deliberately incomplete variants each failed at least one check. A separate reviewer ran an additional eight-case suite, in which the reference passed all eight and each flawed policy was rejected. These are checks of this synthetic prototype, not AI-model performance results.

The recovery assumption

The reference approach depends on the mock provider retaining a stable idempotency key for each event. The worker records pending intent before calling it and stores the returned receipt after acceptance. A real provider with a limited key-retention period or different failure semantics needs a separate assessment.

For teams evaluating coding agents

The proposed buyer is an engineering or AI team that needs to inspect how a coding agent handles integration failures. The scenario exposes a specific contract: external acceptance, durable local progress and event replay must agree. It can support a technical evaluation discussion about task format, reset behavior and acceptance checks.

This is a transparent diagnostic demo: the reference repair and policy variants are visible. It is not a blind coding-agent benchmark; a paid benchmark would require a separate task workspace and evaluation boundary. The sample does not establish how difficult the task is for any particular model, and no model rankings or success rates are claimed. A broader taskset would need buyer-specific requirements, independent difficulty testing and an agreed licensing scope.

Execution boundaries

The prototype uses synthetic data and local resources. It contains no customer code, employer incident records, Azure credentials or production traffic. Local process tests do not establish Azure Service Bus, database-cluster, Docker or production compatibility. Verifier files are separate from the candidate workspace; that separation alone is not a security sandbox when both run under the same operating-system user.

The current sample covers one scenario. Schema migration and incremental ERP synchronization scenarios are possible future work, not included products.

Evaluate the fit before expanding

Indicative paid evaluation pilot: US$250. The proposed scope is one original scenario for one organization’s internal evaluation. Final scope, license, acceptance criteria and delivery are agreed before payment. This is an invitation to discuss fit; there is no checkout or recurring charge on this page.

For a useful first enquiry, include your intended use, preferred runtime, the acceptance checks you need and whether you require exclusive rights. Please do not send proprietary code, personal data or credentials.

Ask about the Integration Recovery Lab pilot

You can also use the existing contact page. The mock scenario is original and synthetic; it is not presented as a real client incident.