[RFC comment] Lost-update race condition

Hello OGC Standards Team,

I would like to submit the following public-review comment for OGC API – Processes Version 2, Part 2: Deploy, Replace, Undeploy (current RFC closing September 5, 2026). The RFC announcement points commenters to GitHub; I cannot reliably use that submission path from my current environment, so please either record this comment in the review or let me know the appropriate non-GitHub public-comment path.

Issue: stale administrative clients can silently overwrite or delete a newer deployed process.

The current draft defines replacement as PUT /processes/{processID} and says the new process definition replaces the old one. It also states that version control is not discussed in the Standard. I could not find a requirement for an HTTP entity validator such as ETag, or for conditional mutation using If-Match, on replace or undeploy. The HTTP status material includes 412 Precondition Failed, but the process-management operations do not appear to define how clients use a precondition to prevent lost updates.

This creates a standard lost-update race:

Client A and Client B both retrieve or otherwise base changes on the same deployed process definition.
A replaces the process.
B, unaware that A changed it, performs its own PUT using stale state.
B’s request succeeds and silently removes A’s change.

The same issue applies to an undeploy/delete based on stale knowledge of the resource. Because a process identifier can represent executable geospatial/scientific workflows, a silent administrative overwrite can also affect reproducibility: the same process ID may later refer to materially different code/configuration without the caller having intended to replace a newer definition.

Suggested change, remaining implementation-neutral:

• Require or strongly recommend that mutable deployed-process representations expose a strong concurrency validator (HTTP ETag is the natural REST mechanism, or an equivalent if the Standard intentionally abstracts it).
• Require replace and undeploy operations to support a conditional mutation using the current validator (for HTTP, If-Match).
• When the supplied validator no longer represents the current resource, reject the mutation with 412 Precondition Failed rather than silently overwriting/deleting the newer state.
• If PUT is allowed to act as upsert, clarify that a request intended to create a missing resource must not accidentally overwrite an existing resource without satisfying the existing-resource precondition.
• Return the new validator after a successful deploy/replace so subsequent administrative operations can be based on the state that actually committed.
• Add a conformance test with two clients based on the same initial representation: after A successfully replaces the process, B’s stale replace and stale undeploy must fail rather than erase A’s change.
• Clarify that the process version property is application/semantic version information and should not be assumed to be an HTTP concurrency validator unless the specification explicitly defines it that way.

This does not require process-history/version-control semantics. It only prevents one current resource state from being unknowingly overwritten by an operation based on an older state, using normal HTTP conditional-request behavior already represented by status 412 in the draft.

Thank you for considering the comment.

Seth Morrow