httptransport: GET vuln report returns 404 when indexing in-progress

[frostmar]

For issue #1962

GET /matcher/api/v1/vulnerability_report/<digest> returns HTTP404 when the index report is not complete, instead of a partial vulnerability report based on whatever is present in the index

This doesn't distinguish between in-progress states (a later request will likely be successful) and the final error state IndexError (a later request will likely still be unsuccessful). I'm not sure what would be preferred - HTTP404? HTTP500 with some error body?

[app-sre-bot]

Can one of the admins verify this patch?

[frostmar]

@crozzy sorry for the bump - just checking if this PR has been overlooked?

[crozzy]

I think this is a good idea. Thinking through re-indexing, will there be a situation where the report is 200OK then is being re-indexed so will be 404Not Found the 200OK again?

[crozzy]

I wouldn't bother with the alias here.

[crozzy]

nit but it might be nicer to compare the state types as opposed to the strings:

var state controller.State
state.FromString(indexReport.State)
if !ok || state != controller.IndexFinished {
...

[crozzy]

@crozzy sorry for the bump - just checking if this PR has been overlooked?

Sorry @frostmar it had indeed fallen through the cracks

[frostmar]

Thinking through re-indexing, will there be a situation where the report is 200OK then is being re-indexed so will be 404Not Found the 200OK again?

I think that will happen, from the user's point of view the vuln report seems to be unavailable for a brief period.

That's pretty much true, however. While (re-)indexing is in progress, there is no valid index report to base a vuln report on, so better to say it's unavailable than give an incorrect one?

As a future extension, there could be a new response instead of HTTP404, to communicate "come back shortly", used when we know we ought to have a completed vuln report available shortly (as indexing is in progress, but hasn't completed) .... but this seems like an edge case that few will benefit from.

[crozzy]

Thanks for the updates, I think it seems like an improvement, @hdonnay is there a situation with clients where you could see this being a problem?

@frostmar looks like you checked in a .vscode file

[frostmar]

... checked in a .vscode file

Sorry, sorted now

[frostmar]

@crozzy / @hdonnay I'm hoping this can make the next release of Clair, if it looks OK to you now?

[frostmar]

@crozzy / @hdonnay bump - can I do anything to progress this please?

[crozzy]

Thanks!