DEMO: Unknown request ID when deleting a test session

[AlexThurston]

environment Demo

testSessionId 86533

vsId N/A

Algorithm registration N/A

Endpoint in which the error is experienced https://demo.acvts.nist.gov/acvp/v1/testSessions/86533 DELETE

Expected behaviour When deleting a test session, the response that is returned is:

[
  {
    "acvVersion": "1.0"
  },
  {
    "url": "/acvp/v1/requests/0",
    "status": "Initial"
  }
]

The request ID associated with this request is not shown in the url so it's impossible to know what request ID corresponds to what operation.

It also doesn't even looks like the request is being registered. If I list my requests prior and after submitting the delete operation, the total number of requests isn't going up.

[AlexThurston]

I just tested deleting a vendor to see if it was resource specific (test session) and deleting a vendor works correctly. Upon submission of the DELETE operation, I am returned a request ID which then is pushed through the appropriate stages and the resource is successfully deleted.

[Kritner]

Hey @AlexThurston I wouldn't say this is exactly "intended" behavior, but it kind of is at the moment, anything that hits our "workflow" queue - things that need approval - are the things that get a request ID. Removing a test session is however automatic and never actually hits our workflow queue.

We should revisit what's returned in the response in this case, but it should be fine from a functionality perspective.

Generally speaking, all meta data is a workflow item that requires approval (be it automatic on demo or manual on prod); where test session specific things (except for certify) don't require approval.

I think we're ok here, just need to figure out a better response to provide.

[AlexThurston]

Understood and that makes sense. You're bang on in that it's the response that is confusing.

That being said, once a test session is deleted, how do I know that it has been deleted? After removing it, I am still able to perform a GET on it. I appreciate that in the documentation it states that it might not be removed immediately, but it'd be good to know that a test session has been deleted (perhaps with the flag in it's meta data) and will be removed at some point if that is still the case.

[Kritner]

I updated the cancel endpoints to return the same sort of payload the previous implementation did:

Regarding what canceling a test session actually does? Potentially nothing, but if the vectors haven't been processed yet they won't be after a cancel. Regarding a vector set cancel, it will be removed from the test session so the test session can be certified w/o that particular vector set.

[AlexThurston]

Would it be useful/prudent/easy to perhaps indicate in the meta data of a test session that it has been cancelled/deleted?

{
    "url": "/acvp/v1/testSessions/86530",
    "createdOn": "2020-05-28T14:50:45.553",
    "expiresOn": "2020-06-28T11:34:25.663",
    "vectorSetUrls": [
      "/acvp/v1/testSessions/86530/vectorSets/219270"
    ],
    "publishable": true,
    "passed": false,
    "isSample": false,
    "deleted": true
  }

Otherwise, there is no way for a user to know that it has been cancelled. I get that if you cancel/delete a test session, you can essentially stop it from generating any un-generated vectors sets, but there would be no way of knowing that those vectors sets won't be forthcoming without an indication that it has been cancelled.