GET request/{request_id} stuck at processing #609
Comments
fliphil
changed the title
|
When it reaches the "processing" state the current process has a manual step (read: human) that needs to be performed to validate and accept the data. For demo, I will eventually implement something that will likely auto-approve, or something to approve them in the morning, so folks don't program in something that expects it to happen at line-speed. Once you submit a request, the eventual process will send an email to notify you that your request has been successfully processed. The email notification is likely to be one of the earliest things to get added once we get 1.0 stabilized. For the moment, send me a note and I can approve any items in the queue if you want to see it advance (I approved the several that I saw just a bit ago). |
|
Probably missed some discussion on this, but there is a manual(production) or once daily(demo) step required for all new vendors ? How about all other layers of registration such as modules and OEs ? |
|
Yes. The data needs to be vetted by something to insure that the input is valid. Currently, that's a human, since that was the fastest way to get this up and running. Validity more or less entails:
We don't expect bad input as anyone who does it will face a loss of their access, but nonetheless we need to have some sort of mitigation. Auto checking for XSS and other bad input is a tractable problem. Exact duplicates can be easily managed, but near (or semantic) matches are a tougher problem (I.B.M. vs IBM vs IBM Corp. vs International Business Machines Corporation, etc...). The expectation is that after the initial flurry of creating the baseline of metadata, that most of the time the existing data will be sufficient with a new product version being added here and there. It's not yet implemented, but auto-approving a validation will be possible as long as all of the meta-data is already accepted. |
|
Regarding duplicates, here is what I get from GET /vendors. Doesn't seem like that's what is intended. [ { |
|
The data you are receiving is the actual data currently in the database. As I mentioned on the call, cleaning this up is a longer term activity that will still need to be undertaken. |
|
Cleaning up the duplicates is not really our concern :) What I see is a situation where:
|
|
I guess that is the intent. I am using the following steps with my client:
|
|
@hbooth, @fliphil @smuellerDD @atvassilev Exactly my understanding as well. 1-4 is significant overhead for a client. By performing 1-4 operations the client is essentially managing the database for the server. That seems backwards. For #5, you are saying the client must maintain state, correct ? Even when the PUT is not "realtime" ? |
|
Yes, for all steps we need to retain a state: the ID and the information whether it is a request ID or a real vendor/person/oe/dependencies/module ID. |
|
Is this still an issue? As a separate but related fix, we do have the intention of automating the approvals for the demo environment. |
|
Will look into this tomorrow to test |
|
I've successfully requested a FIPS validation on the demo server and it was later approved so I don't think its an issue any longer. |
Hello,
The server appears to be stuck at the "processing" status when my client queries with a GET request.
It moves past the "initial" status to "processing", but after 5 minutes of retries there is no update to the status.
[{"acvVersion":"0.5"},{"url":"/acvp/v1/requests/19","status":"processing"}]
This happens on the first Vendor that try to register.
It fails there because my client attempts to register the Vendors first, but if needed I could shift the order around and try something else such as a Person.
The text was updated successfully, but these errors were encountered: