»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.