.png)
Concurrent Configuration Edits: Prevent Lost Updates with a Verified Revision Check
Two engineers can each save a valid configuration while the later save quietly removes the earlier change. Where an integration exposes a documented revision or HTTP conditional-write mechanism, use it to detect stale edits before applying a change. A successful save alone does not prove that every intended setting survived.
Original conceptual illustration; not a specific product, live software screen or customer installation.
Key takeaways
Keep the validator with the reviewed baseline.
Do not overwrite a conflict by blind retry.
Read back intended and preserved fields.
1. Define the shared object and its owner
Identify exactly what the API treats as one resource: a point mapping, an equipment record or a complete configuration document. Determine who can edit it and whether background services also write to it. The conflict boundary may be larger than the field visible in the editor.
This article describes a design and acceptance pattern, not a claim that every PLC, gateway or software interface supports conditional requests. Read the exact API contract first. Some services use a numeric revision in the body; others expose HTTP entity tags. These mechanisms are not interchangeable without documentation.
2. Retain the version that was actually read
For an HTTP endpoint supporting it, retain the strong ETag returned with the representation. RFC 9110 defines If-Match as a precondition using strong comparison. It is intended to help prevent lost updates when clients modify the same resource in parallel.
A wildcard If-Match checks whether a representation exists; it does not establish that it is the version the engineer reviewed. Use the documented specific validator where the requirement is to protect a particular revision. Keep the original representation and proposed field changes together for review.
3. Exercise a hypothetical two-editor conflict
Engineers A and B read revision R1 in an isolated test. A changes the description and successfully saves R2. B then attempts a range change using the validator for R1. The test should demonstrate that the stale edit cannot silently replace A’s description.
A failed precondition commonly appears as HTTP 412. Record the actual documented response and resulting stored representation. There are protocol nuances for a change already applied, so do not rely on one status code without reading the resulting resource and the service contract.
Original explanatory diagram. Hypothetical values and proposed checks are described in the text; this is not a product specification or field result.
4. Resolve rather than blindly retry
On a conflict, fetch the current representation and compare it with the baseline and intended edit. Ask whether the changes affect the same meaning, even if they occupy different fields. A range and its unit can conflict semantically despite being separate JSON properties.
Reapplying the whole old document with a fresh validator defeats the protection. Instead, prepare a reviewed change against the new baseline and repeat the conditional operation. Preserve unrelated fields. This is especially important where omission, null and default values have different update meanings.
Read the complete resource and retain its validator.
Create a controlled competing change.
Confirm a stale write is detected.
Review the difference and verify the final resource.
5. Retain evidence beyond the save response
Read back the resource and verify both the requested change and the fields expected to survive. Keep the old revision, conflict evidence, approved resolution and resulting revision in the project record. Redact secrets before sharing logs and never include credentials in screenshots or examples.
A revision check controls concurrency at a defined resource boundary; it does not establish safe control logic, authorisation or correct physical configuration. Changes affecting equipment require the site’s application review and validation process. ProSense can discuss the integration requirement once the exact API documentation and change ownership are available.
Related guide and project resources
Technical references
Need help with your application?
Send the relevant point list, equipment documentation and a sanitised example of the behaviour you need to verify. Confirm the available functions and integration requirements for the exact equipment and deployment.
