Closed cd-rite closed 3 months ago
This requires more design work than described above. The handler needs to behave differently based on the specific request that errored during the request pipeline (create asset, map stig(s), post reviews).
A 400 error during asset creation must be analyzed to see if the error is from a duplicate name. If it is, the error can be logged and not rethrown and the pipeline can continue. That is what the current code does.
If any other 400 error response is received from the asset creation request, then the error must be rethrown so the request pipeline for that asset stops. The current code has this behavior but it also raises the apiOffline alarm, which is not correct.
A 400 error in response to the request to map stigs or post review should be rethrown to stop the pipeline for that asset. But again, no apiOffline alarm should be raised.
It is important that only the request pipeline for the asset that is generating the 400 errors is stopped on error. There needs to be a more granular error handling in cargo.js/resultHandler() so other assets being handled during the same batch are allowed to proceed. The current code stop the entire batch upon any error, which is not necessary.
An addendum to the above. The 400 condition that Watcher checks for will never be satisfied. The API actually returns status 422 Unprocessable
when there's an Asset name collision during creation, with a message of Duplicate name exists
.
From STIG Manager:
if (err.code === 'ER_DUP_ENTRY') {
throw new SmError.UnprocessableError('Duplicate name exists.')
}
api.js line 64: if (e.response?.statusCode === 400 && e.response?.body?.message === 'Duplicate name') {
remove second clause of if condition (ie. all 400s)