usnistgov / ACVP-Server

A repository tracking releases of NIST's ACVP server. See www.github.com/usnistgov/ACVP for the protocol.
46 stars 16 forks source link

Cannot read a test session for a period after it is created #232

Open AlexThurston opened 1 year ago

AlexThurston commented 1 year ago

environment Demo (and probably production as well)

testSessionId N/A

vsId N/A

Algorithm registration N/A

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

Expected behaviour It looks like if you attempt to read a test session for a period after it has been created, nothing is returned.

Additional context It looks like when a test session is created and was successful, its relevant information is returned as expected. However, if you try to read that test session right after (or up to 30 seconds after) on occasion nothing is returned in the body nor is there any error to indicate that something is wrong.

AlexThurston commented 1 year ago

Looks like it's closer to 60 seconds before the read of a test session will return anything.

livebe01 commented 1 year ago

Hi @AlexThurston, what you are experiencing/observing is an artifact of our systems architecture.

You'll notice that the responses for POST /testSessions and GET /testSessions/{testSessionId} are nearly identical. But in the two cases, the information in the responses come from different places w/in the ACVTS system and this has to do with its architecture.

Our systems architecture has a 1) publicly accessible component and 2) a non-publicly accessible component that lives on an internal network.

POST /testSessions hits the public component which a) creates the test session id. The public component then b) returns the newly created test session information to the client and c) passes the information regarding that new test session to the non-publicly accessible internal component of ACVTS. That internal component d) creates the actual database records for the test session and kicks off the vector set generation process. Those internal database records are then e) replicated to a database that lives on the public component. GET /testSessions/{testSessionId} hits the ACVTS public component and the test session information is queried for in the public database.

What you're observing is the ~60 second lag time involved with steps c through e. After the public component performs b and c, it no longer has any knowledge or awareness of that test session until the database records created by the internal component get replicated back out to the public component.

We want ACVTS' behavior to be well defined and it sounds like it's not for the scenario you're describing. When we get a chance we'll look into what is returned and what should be returned when GET /testSessions/{testSessionId} is used to query a test session that does not yet exist.

Thanks!

-Ben