To recreate this:
- Add the xnat/debug-command:1.5 docker image to your XNAT with Container Service.
- Add the command listed at the bottom of the ticket to the image.
- Create a new project. Enable the new command in the project.
- Create two new project resources, A and B.
- Delete resource A via REST. That is, with a DELETE to /data/projects/$PROJECTID/resources/A.
- Refresh the page. Find the container launch option in the actions box and select it.
- In the container UI displayed, both resources will be present.
Kate originally found the issue. I've listed her more technical comments below:
When I delete a project resource via API (DELETE to projects/PID/resources/RESID as occurs when you delete via Manage Files), the resource is removed via CatalogResource.java>handleDelete(), which deletes with SaveItemHelper.authorizedRemoveChild(...). However, if I then bring up the container launch UI for a container that uses project resources, the deleted resource still appears in the list. I believe this is because the project is cached via DefaultUserProjectCache and this cache entry isn’t updated from SaveItemHelper.authorizedRemoveChild(...).
1) does that seem like a correct explanation of the behavior?
2) if so, how do I get that cache to update? am I supposed to trigger an event?
Incidentally, I don’t see the same thing when adding a resource, I believe because DefaultCatalogService>insertProjectResourceCatalog calls working.setResources_resource(resourceCatalog);, which is operating on the cached object, before calling SaveItemHelper.authorizedSave(...)
Adding XDAT.triggerXftItemEvent(parent.getItem(), XftItemEvent.UPDATE); to SaveItemHelper.removeItemReference(...) fixes the issue… not sure if this is the appropriate thing to do, though