Prevent an AI retry from creating a second record
Design and test an AI workflow’s retry behavior so an uncertain response does not create another business record. Includes concurrent-request cases.
Give each authorized business operation a stable identity before an AI workflow tries to create a record. If a request times out, the next attempt must refer to that same operation and determine its outcome. A second fluent instruction to “try again” should not become a second job, invoice draft or purchase request.
This is an integration design and acceptance guide. It does not claim that every Odoo method or AI tool already prevents duplicates.
A timeout leaves the outcome uncertain
Consider an invented assistant creating a draft service request. The application sends the request, the server creates record J-204, and the response is lost. From the caller's perspective, the operation timed out. From the database's perspective, it succeeded.
A blind second create can produce J-205 for the same intended work. Asking the model whether the first request probably worked cannot establish the database state.
AWS's guidance on safe retries describes caller-provided request identifiers and the need to handle their record together with the corresponding changes atomically. That principle is useful here: preserving the identity of the intended operation is part of the software design, not a wording instruction to the model. AWS: Making retries safe.
Define what the identifier means
The system owner should write a contract for the operation. Include the caller, operation identifier, approved input version, intended action, resulting record identifier and recorded outcome. Decide how long the duplicate-detection evidence must remain available for the workflow's retry and recovery behavior.
The same identifier with the same approved input should refer to the same intended operation. A new business request needs a new identity. Reusing an old identifier with changed content should produce a visible conflict rather than silently changing what the earlier approval meant.
Those are proposed acceptance requirements. Have the developer explain where they are enforced and how concurrent requests are handled. A separate “search for an existing record, then create one” sequence can race when two workers run together; both may search before either creates.
Odoo 19.0's JSON-2 API documentation states that each call has its own SQL transaction and that multiple calls cannot be grouped into one transaction by the caller. It recommends a single method for related operations that need to be atomic. Check the supported method and hosting approach for your design; ordinary create calls are not documented here as automatically idempotent. Odoo 19.0 external API.
Test the failures deliberately
Use a non-production environment with fictional records. The test team should be able to interrupt responses and send concurrent requests without affecting real work.
| Case | Expected evidence |
|---|---|
| Normal request | One resulting record tied to the intended operation |
| Response lost after success | Retry identifies the prior result without another record |
| Same request arrives simultaneously | One business effect; both callers receive a resolved outcome |
| Same identifier, changed input | Visible conflict requiring a defined decision |
| New authorized request with similar content | A distinct operation can proceed |
| Delayed retry after recovery | Behavior follows the documented retention and recovery rule |
| Failure before any business effect | Safe retry or explicit unresolved state, without invented success |
Inspect resulting records as well as response messages. A green automation run can coexist with a duplicate business record. Retain operation IDs, timestamps, outcomes and record references in the test evidence, with sensitive input excluded from general logs.
Give uncertain outcomes an owner
Some failures may require investigation. The operator needs a view that distinguishes succeeded, failed and unresolved operations, plus a safe way to resume from the recorded state. Do not let an unresolved request disappear into a retry loop.
Use the AI permissions worksheet to limit what the integration identity can do. Passing these retry cases establishes evidence for one defined operation in one configuration. Repeat the affected cases when the tool, method or approval boundary changes.