Closed andrewazores closed 2 years ago
Since this issue requires API changes (introduction of a new status code) should I apply these changes to just the v2 version of the TargetSnapshotPostHandler
or both v1 and v2? From meetings, I remember hearing that we'll pick and choose which changes from main to incorporate into the v2 branch.
I think in this case we can apply it to both. I would consider this to be a bugfix, and that clients shouldn't be relying on the 0-length snapshots being valid and returning a 200 status.
It is currently possible to take a Snapshot recording even when the target VM has no running recordings, or has only empty recordings, etc. This will reliably create recordings with 0 length.
This can be easily reproduced:
Or:
These 0-length snapshots cause various problems for other features:
Report Generation:
View in Grafana / Download Recording / Download Report:
Attempting to archive such a recording appears to fail silently in the web-client UI, but the backend logs show this:
When a Snapshot is created, Cryostat should check that the resultant recording is non-empty. If it is empty then the snapshot should be deleted and an appropriate HTTP response sent to the user, other than a 200, so that there is some indication that the request was received and processed but there is no result (HTTP 204 sounds appropriate, but this implies there is no response body. HTTP 202?)