Closed ansell closed 5 years ago
image-service-1.0.9 was deployed to the images-dev server still. Switching it to use 1.0.10-SNAPSHOT and then re-initialising and reindexing fixed this issue.
I didnt actually change anything for deletes. Deletes from the index are asynchronous (uses job queues). So there is a lag between the delete and it being removed from the index
There is a clear change in test behaviour for deletes between 1.0.9 and 1.0.10-SNAPSHOT. It started to work after deploying 1.0.10-SNAPSHOT where it failed with 1.0.9
Just to clarify, the change in behaviour in 1.0.10-SNAPSHOT is that the image is successfully removed from the search index as expected, and viewing the image using its direct URL now clearly shows it as "deleted". Those two changes seen during testing were the reasons this issue has been closed.
ok. That should have been the behaviour since 1.0.8. Perhaps something was broke, but we'll put efforts into testing with 1.0.10. Onwards and upwards !
Deleting images using the X button does not remove them. They appear still in the search results, on their original page (without any indication that they have been deleted).
This is part of the image service testing plan, but not sure what the exact intended steps are for it.
For testing I uploaded the following image:
https://images-dev.ala.org.au/image/bedcfd65-f0a3-44c1-8fc7-96f53f050cc2
In that specific case, developer tools shows the call to the following URL coming back with HTTP 200, so that eliminates a Javascript bug but there may be other issues on the server, as we have other cases in other Grails apps where HTTP 200 is sent even though errors occur.
https://images-dev.ala.org.au/image/deleteImage/bedcfd65-f0a3-44c1-8fc7-96f53f050cc2