»Another user has updated this resource…« in production environment

[krns]

In our production environment a normal interaction with nova looks like the following screenshot.

(German translation for Another user has updated this resource since this page was loaded. Please refresh the page and try again.)

The updated_at timestamp is always one second ahead of the _retrieved_at timestamp.

Maybe related to #408 and #236

[taylorotwell]

Since we can't recreate this, it is probably a system / server clock issue. Do you have a way to reliably recreate it on our end?

[pehbehbeh]

In case someone stumbles on this: Our AWS EC2 instance had an incorrect time setting (3 minutes in the future). We configured chrony as Amazon suggested. You can add this as a Forge recipe:

sudo apt update
sudo apt -y install chrony
sudo sed -i -e '1iserver 169.254.169.123 prefer iburst\' /etc/chrony/chrony.conf
sudo /etc/init.d/chrony restart

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html#configure_ntp

[pr-baernholdt]

I have the same issue on a shared hosting for one of our small projects, and this is not a possible solution for us.

As Nova is targeting small to medium projects, there might be some other people like us who have the same issue and don't want to pay to buy a dedicated server, VPS, VM with root access or use public cloud providers due to the price.

Does that mean even if either server or the client's clock is a few seconds incorrect they cannot update any resource?

[bernhardh]

I had a similar issue and for me the error was on wrong timezone set in config/app.php. I had to change it form UTC to my own timezone.

` /*
|--------------------------------------------------------------------------
| Application Timezone
|--------------------------------------------------------------------------
|
| Here you may specify the default timezone for your application, which
| will be used by the PHP date and date-time functions. We have gone
| ahead and set this to a sensible default for you out of the box.
|
*/

'timezone' => 'Europe/Vienna',`

[pr-baernholdt]

Thanks @bernhardh for your feedback. I have the right timezone in the config file:

    'timezone' => 'Europe/Copenhagen',

But as far as I check the value for _retrieved_at is a few seconds different from the value for the updated_at in the database due to having inaccurate time on server, and we cannot do anything for it on a shared hosting which is the only option for us.

A temporary solution would be to manually add the difference, like this:

namespace Laravel\Nova\Http\Controllers;
...

class ResourceUpdateController extends Controller
{
    private $diff = 60;
...

    protected function modelHasBeenUpdatedSinceRetrieval(UpdateResourceRequest $request, $model)
    {
        $processedTime = Carbon::createFromTimestamp($request->input('_retrieved_at')  + $this.diff );

        $column = $model->getUpdatedAtColumn();

        if (! $model->{$column}) {
            return false;
        }

        return (
                $request->input('_retrieved_at') &&
            $model->usesTimestamps() &&
            $model->{$column}->gt($processedTime)
        );
    }
}

The problem is that I have to update this value every now and then to make sure it works with the new time difference.

[merlinresponse]

We cannot seem to get rid of this. Could it be avoided when working with just one user, to omit the problem for our specific development? (We are using Digital Ocean / Forge)

[audetcameron]

Howdy I get a similar issue when using homestead and nova, Where should I look?

[reyezJelle]

I had the same issue, and It looks like the _retrieved_at timestamp is based on the time on your computer. I reproduced this problem by adjusting the local time on my mac. The servertime was one minute off from my local time which caused the issue.

It seems to me that this will cause problems everywhere. Shouldn't the _retrieved_at time not also be server-based?

[mislam]

This is happening when I wait little bit then press update. If I quickly click update within 3-4 seconds, then it updates without any problem. This is a severe issue for us as it significantly slows down our daily business. Need a fix ASAP.

[phuclh]

I have the same issue too.

[audetcameron]

We ended up having our office computers synced to a more reliable world clock.
check your server time date +"%T.%N" against your local computer time.

[pleone]

Why is this issue closed? Not being able to reproduce does not mean there's no issue.
@taylorotwell @davidhemphill can you please clarify how this check works ?

Checking the updated date seems pretty odd to me.
Anyway, is there an option to disable this weird behaviour ?

Documentation on this is quite lacking ( https://nova.laravel.com/docs/2.0/resources/#preventing-conflicts )

Thanks.

[Francois-Francois]

@pleone agree

[pehbehbeh]

Anyway, is there an option to disable this weird behaviour ?

We had to bypass this (completely broken) functionality with a custom middleware in all our Nova installations: #1082 (comment)

[Jaspur]

Yea, fix would be great..

[jbrooksuk]

@Jaspur this is fixed.

[Jaspur]

@jbrooksuk which release? I'm on the latest version and it still occurred

[jbrooksuk]

You need to disable Traffic Cop...

[Jaspur]

Hmm, it is in the docs, but not visual? :') https://www.dropbox.com/s/bqnqhobmoxvmqzt/Schermafdruk%202019-12-05%2010.06.07.png?dl=0

[jbrooksuk]

https://nova.laravel.com/docs/2.0/resources/#disabling-traffic-cop

[Francois-Francois]

@jbrooksuk @krns @pehbehbeh @Jaspur @pehbehbeh I think I have a workaround. It looks like this is related to bad time sync on the computer. I've forced some users to update the configuration, and it looks like the problem is solved on their side. What I think is that servers are synced by ntp, and have correct timestamps. When the browser uses a function to generate current timestamp, it differs from the server when sending the request, so Trafic Cop is warning us.

[jbrooksuk]

@Rikless this is indeed usually the solution and something I'll add to the documentation now.

[shihazali]

public static $trafficCop=true;

You may also override the trafficCop method on the resource
public static function trafficCop(Request $request)
{
return static::$trafficCop;
}

[Synchro]

I'm getting this with Laravel 6.9 and Nova 2.9.2. It can't be a clock sync issue because it also happens when running locally with artisan serve, when client and server are exactly synchronised (because they use the same clock). It's possible they might have different time zones (servers usually being set to UTC, browsers usually being local time), but I'd definitely classify that as a bug if it's not taken into account. Oddly I don't get this with a remote server whose time does differ very slightly!

[jbrooksuk]

You can disable this https://nova.laravel.com/docs/2.0/resources/#disabling-traffic-cop

[bruno-rodrigues]

@Jaspur this is fixed.

Sorry but we cannot disable this feature, and "Just disable it" does not sounds like a solution to me.

[grinevri]

I suggest for Nova developers to show confirmation dialog such as "Another user has updated this resource... Are you sure want to save your changes? Yes, No".

When people follow the recommendation "Please refresh the page and try again" they may be discouraged because of losing their changes and valuable time.

[eComEvo]

Possible solution to this that worked for me that involves fixing the timezone on MySQL to match what is in the Laravel app.