Deleting archived recording does not remove its cached report

[andrewazores]

Steps to reproduce:

1. Create a recording
2. Let it run for some time, then archive it
3. Request a report for the archived recording and note how long it takes to receive a response
4. Download the archived recording to your local machine
5. Re-request the same report again and note that the response time is much shorter, due to the caching. This can be verified by checking the Cryostat logs and seeing if a SubprocessReportGenerator was forked (or in feat(reports): sidecar container report generation #779 , if a request is made to the sidecar container).
6. Delete the archived recording
7. Re-upload the archived recording
8. Re-request the report for the re-uploaded recording and note that the report was still cached by Cryostat, by the response being very fast and no SubprocessReportGenerator fork or sidecar request showing in the logs

So the cache invalidation is broken in RecordingArchiveHelper.deleteRecording. It seems like the path that the cached report is stored at is different from what the helper expects it to be. Therefore this bug probably stems from ArchivedRecordingReportCache.

[hareetd]

I did some investigation and while debugging, this behaviour is observed for the dropdown report but not for View Report. In fact, besides the initial backend call the first time a dropdown report for an archived recording is requested, the backend receives no calls for subsequent dropdown report requests for the same recording, whether it has been deleted and then uploaded, or not (i.e. the backend ArchivedRecordingReportCache is not used at all).

However, for View Report the report caching is working as expected. I think what's happening is that the browser is caching the dropdown report, which could be fixed by tinkering around with ReportFrame.tsx on the frontend (if that component is indeed the one that houses the dropdown report).

[hareetd]

I commented out lines 54-57 in Report.service.tsx (see here) which ensures the dropdown report won't be retrieved from session storage. Instead, a backend request is sent every time the dropdown report is requested, in which case the ArchivedRecordingReportCache behaves as expected.

When you have a chance could you confirm that this is indeed the case? If so, then I think the actual bug is that reports aren't deleted from session storage upon their corresponding recording's deletion.

[andrewazores]

Seems like a good plausible explanation to me.

[hareetd]

Closed by cryostatio/cryostat-web#360