File/Image delete causes 409 error response on page update

[29avet1]

• Laravel Version: 10.19.0
• Nova Version: 4.27.14
• PHP Version: 8.2

Description:

When we delete a file or image on page edit, then we click the update button, it throws a 409 error "Another user has updated this resource since this page was loaded".
It is caused by the fact that after deleting the image it touches the row in db, sets the image name to null, and also "updated at" is getting refreshed. By this, the "retrieved_at" value is responsible for checking whether another person has edited this resource or not, becomes outdated.
I saw that the nova file input triggers an event "file-deleted", which in "HasOneFiled.vue" is handled and triggers another "update-last-retrieved-at-timestamp" event, which I suppose updates the retrieved_at value to avoid this issue, but in "Update.vue" the "handleFileDeleted" method is empty and not triggering the "update-last-retrieved-at-timestamp" event.

Detailed steps to reproduce the issue on a fresh Nova installation:

1. open the Edit resource page with an image input. upload an image and save, or open an edit page that already contains an uploaded image
2. delete the image, then click the "Update" button. it will throw an error.

[Keko-94]

Same problem with the latest Nova v4.34.3.
Any update of this ?

[jeremynikolic]

Thanks @29avet1 for reporting this, I'll be looking into it 🕵️

[jeremynikolic]

Seems like I can't reproduce this 🤔
If you still encounter the issue please provider a reproducing repo 🙏

After looking at how components are stacked and the chain of events in the described case, all is good with updating images:

• FileField -> file-deleted
• Panel@file-deleted -> update-last-retrieved-at-timestamp
• Update@update-last-retrieved-at-timestamp -> does update its lastRetrivedAt

[29avet1]

@jeremynikolic
The problem still exists in v4.35.0
This happens in case you use an s3 storage disk. I checked with AWS s3 and Cloudinary.
For the local disk, it works well.

  Image::make('Top image')
      ->disk('cloudinary_memberstory')
      ->hideFromIndex()
      ->rules('nullable', 'image', 'mimes:jpeg,jpg,png', 'max:10240')
      ->preview(fn() => $this->topImageUrl)
      ->prunable(),

[jeremynikolic]

I've rerun my tests on different storages, as well as file and image fields, same as last time.
Still unable to reproduce this issue 🤔

[crynobone]

Hey there,

We're closing this issue because it's inactive, already solved, old, or not relevant anymore. Feel free to open up a new issue if you're still experiencing this problem.