Add "cookies" to asynchronous operations with a resource (UI, REST API, groovy LRM manipulation?)

What feature do you want to see added?

When the HTML table with resource status (and reserve/unreserve/steal/... buttons) is returned to a browser, it represents a snapshot of how things were in the past. Whether one second or a few minutes ago - that information may be obsolete by the time someone wants to act on it.

A sufficiently privileged user may inadvertently break things by e.g. releasing a resource from a job deemed stuck or some post-mortem investigation completed, just because their data table was rendered a few minutes ago and since then someone else got that resource and is actually using it.

• This is roughly equivalent to the old problem we have (had) when lockable resource population and states were edited through the global configuration page, corrupting the live LR state data when that page was saved and old LR state imposed.

This feature suggests extending the REST API calls that modify resource data (at least locked/reserved/stolen state, but maybe also notes, properties, etc.) by adding a cookie (e.g. json or hash of previously known state). So for asynchronous usage like REST API calls and configuration UI, the caller can say "I want to impact resource that had THIS state the last time I looked" and the server can proceed with the modification if the current state in LockableResourceManager is still the same, or reject the operation if somebody/something else has already changed it.

Technically speaking, non-REST API users (e.g. groovy scripts in Jenkins Console or pipelines that side-step the lock{} semantics, e.g. to pass a resource between separate jobs) could benefit from such an extension as well, but it must be optional (new method names? or just a new signature with more arguments?)

Upstream changes

No response

Are you interested in contributing this feature?

Possibly, if dayjob lets me prioritize this :)

Start by tracing the REST API operations that modify resource state and the LockableResourceManager state they update. Compare those paths with the configuration UI and the optional Groovy or pipeline APIs mentioned in the issue. Done should include rejecting a change when the previously observed state is stale while preserving current behavior for callers that provide no cookie.