Skip to content

Send the web socket events after the transaction #806

@ReidyT

Description

@ReidyT

For now, the WS is send inside the move transaction. It should be send after to allow the query-client to invalidate the queries correctly.

Current state and problems

sequenceDiagram
    participant Client
    participant Server

    Client ->> Server: Move items
    Server -->> Client: HTTP 202 Accepted
    par in the transaction
        critical transaction
            loop Move items
                Server ->>+ Server: Move item
                Server -->> Client: ws { op: 'delete', source: item }
                Client ->> Client: useChildrenUpdates manually update cache for source
                Server -->>- Client: ws { op: 'create', destination: item }
                Client ->> Client: useChildrenUpdates manually update cache for destination
                Server -->> Client: Websocket feedback
                Client ->> Client: useItemFeedbackUpdates display message
            end
        end
    and sending when transaction is not terminated
        Client ->> Server: GET item [id]
        Server -->> Client: HTTP 200 with staled item (still in transaction)
    end
Loading

The problem here is that when we want to use useChildren with a filter (like the type of the item), a new key is created (something like ['items', 'children', $id,['FOLDER]). To be sure to update correctly the data, it may be mandatory to update all the children caches. The problem with that, is we have to update caches correctly depending on the filter applied on them.

Another problem is that manipulating the cache manually can cause issues and it is error prone. But for now it is not possible to invalidate the cache. Indeed, a new request will be send to the server, but because the transaction is not terminated, the staled data will be sent.

Ideal solution

sequenceDiagram
    participant Client
    participant Server

    Client ->> Server: Move items
    Server -->> Client: HTTP 202 Accepted
    loop Move items
        critical transaction
            Server ->> Server: Move item
        end
        Server -->> Client: ws { op: 'delete', source: item }
        Client ->> Client: useChildrenUpdates invalidate cache source
        Client ->> Server: GET item source
        Server -->> Client: HTTP 200 with correct committed item
        Server -->> Client: ws { op: 'create', destination: item }
        Client ->> Client: useChildrenUpdates invalidate cache destination
        Client ->> Server: GET item [id]
        Server -->> Client: HTTP 200 with correct committed item
    end
    Server -->> Client: Websocket feedback
    Client ->> Client: useItemFeedbackUpdates display message
Loading

Ideally, the query-client should invalidate the cache for the source and destination parent items and should receive the correct committed data.

This allows to notify user concerning successful and errors, as well as not rolling back successful moved items (comparing to previous implementation).

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions