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.