Prevent overlapping request edits

Step 1: Add semaphore support to the entity

Optional if we don't care about potential collisions

In the respository layer surround the fetch and conditional insert / update with a transaction If the record fetched has a semaphore number != provided semaphore fetched, then don't do update Is version column usable for this or does it have another purpose?

Reason: If two users try to save an Entity at the same time the second one does not know the state of the system and should not be able to save.

Consideration This may cause too many jobs to transition their entity to error state which may or may not be desirable. An env can be added to turn this semaphore support on or off. A transition (in this case reserving) can request to respect the semaphore when calling the repository layer

Step 2: Support to reserve the request

Option 1 - db only (safe bet)

    2 new fields on Request entity ReservedBy ReservedUntil

The user reads to get the current semaphore and transitions SelfToSelf if they are able to check it out then reads to get the new checked out semaphore.

// Example pseudocode
let request = await requestService.getRequest(123);
isReserved(request)
    ? alert('this is being worked by another employee')
    : requestService.reserve(123)
        // re-fetch to get new record with updated semaphore
        .switchMap(() => requestService.getRequest(123))
        .subscribe(
            res => request = res;
            error => alert('Problem')
        )

Option 2 - websocket

Use serverless websocket and dynamodb to stream a reserved array to browser.

browser subscribes to reserved array when landing on request Request is in read only state Example serverless.com implementation is a half dozen lines of javascript here

• Request is in read only state
• User subscribes to array of checked out items
• user requests item with toggle at top of page
• when user subscription of checked out items shows user has visible request becomes editable