Direct answer
No. Inertia does not provide atomicity for shared data updates across concurrent requests, because there is no cross-request shared state to update. Shared data is evaluated per HTTP request and merged with page props for that single response. Two simultaneous requests do not interfere with each other in Inertia itself.
Confirmed behavior
Inertia treats shared data as request-scoped. Each incoming request invokes the shared data closure you configure, producing a fresh object for that request. The library then merges that object with the page-specific props before rendering and sending the response.
Because the merge occurs per request, each request receives its own copy of the shared key values. There is no built-in cross-request race condition on the merge itself.
Likely explanation for perceived races
A race can only appear if the value returned from the shared data closure references mutable state that lives outside the request scope, e.g., a global variable, singleton, or an in-memory cache that is mutated during request handling. Inertia provides no locking or atomicity guarantees for such external state.
The documentation assumes shared data is immutable or recreated per request. If you mutate a shared object after it is returned from the closure, or you return the same mutable reference for every request, concurrent workers can observe interleaved updates.
What to check in your case
- Confirm the shared data closure returns a new object each request, not a reference to a long-lived mutable object.
- Treat values returned from the closure as read-only for the duration of the request.
- If the shared value is derived from external mutable storage, apply synchronization at that storage layer, not in Inertia.
Practical verification
- Make a test route where the shared key is set to a request-specific value, such as a timestamp or random number generated inside the closure.
- Send two concurrent requests and inspect the returned page props. Each response should contain the value computed for that request only.
- To detect a shared mutable reference, log the object identity inside the shared data closure. Identical identities across requests indicate a shared mutable object that needs external synchronization.
Missing diagnostic detail that changes the recommendation: are you returning a fresh object per request from the shared data closure, or returning a reference to the same mutable instance stored outside the request? If it is the latter, the fix is to clone or recreate the value per request and move synchronization to the underlying store.
inertiajs