Traffic Cop improvements

[wimski]

• Laravel Version: 8.52.0
• Nova Version: 3.27.0
• PHP Version: 7.4.21

Description:

I'm experiencing a bug with the traffic cop feature that has been reported multiple times. Using Update & Continue Editing on a resource I frequently get the Another user has updated this resource since this page was loaded error message even-though I'm the only user (this is reproducible in my local setup).

This proposed solution seems like a structural fix. Is anything being done with that?

Related issues

• When updating a resources for second+ time, clients with system time set few minutes in the past get the error: "Another user has updated this resource since this page was loaded. Please refresh the page and try again." #3203
• Client side clock drift causes 409 on Save after "Update and Continue Editing" #2458
• Nova 409 error after updating resource 2-nd time #1853
• Updating a resource on distant server results in a 409 #1082
• Update & Continue Editing throws error if attempted more than once #1004
• »Another user has updated this resource…« in production environment #601

[crynobone]

updated_at suggestion covers some of the use cases, fields with deletable file/image can trigger model updated_at outside the scope and it doesn't have access to updated_at. Even if it does it is no longer a truth source value (someone may already change other fields on the same model).

hashing suggestion only works with the assumption that each field will correspond with a specific modal attribute and there no mutation happening either via fillUsing(), model observer, or model casting.

[wimski]

updated_at suggestion covers some of the use cases, fields with deletable file/image can trigger model updated_at outside the scope and this doesn't have access to updated_at. Even if it does it is no longer a truth source value (someone may already change other fields on the same model).

Isn't there another reliable timestamp on the server which can be used? Something from the ActionResource/ActionEvent that keeps track of mutations perhaps?

hashing suggestion only works with the assumption that each field will correspond with a specific modal attribute and there no mutation happening either via fillUsing(), model observer, or model casting.

Agreed, hashing isn't an option.

---

The whole point is that you can't match a client-side timestamp with a server-side timestamp, because that's comparing apples with oranges. We somehow need an apple from the server-side to do the comparison later on or this feature is fundamentally buggy.

[crynobone]

Isn't there another reliable timestamp on the server which can be used? Something from the ActionResource/ActionEvent that keeps track of mutations perhaps?

Over-complicated and can potentially cause more unexpected results, and it would be harder to debug.

We somehow need an apple from the server-side to do the comparison later on or this feature is fundamentally buggy.

It is working only in certain criteria, buggy to others.

I wish we can have another way of preventing overriding already replaced value instead of completely abandoning local change if a model has been updated by someone else. But for now, the suggestions only cover some and not all scenarios, and possible to create another fundamentally buggy feature.

[mohitYogi]

I'm not sure if it is a good solution or not. Can we send the latest timestamp (may be time()) from the server to the client with the response and then initialize the lastRetrievedAt in Vue with that timestamp.
It doesn't resolve much but can solve issues raised due to clock mismatch of user & server.

[skylex]

It just happened to me on Nova 4.19 & Laravel 9.19 with a user having a slightly incorrect time on his computer.

@crynobone I don't know how it works internally, but the suggestion from @mohitYogi seems good. Or store the time offset between the client and the server on client-side to do the math if needed.