x/vuln: unexpected publishing latency about go

[stapelberg]

I suggest printing a message when starting the request, not afterwards. That way, if the program hangs, it’s very clear what’s happening: the last line will tell you exactly what it’s trying to do.

Hiding this behind a verbose flag sounds reasonable.

[cherrymui]

cc @golang/vulndb

[zpavlinovic]

Thanks for reporting this.

Yes, govulncheck does not do any type of caching. We don't print anything related to that so as to not confuse the users. They shouldn't even be aware of its (non-)existence.

It is hard to tell why you are seeing this. We'll try to dig on the server side for more information.

[stapelberg]

Yes, govulncheck does not do any type of caching. We don't print anything related to that so as to not confuse the users. They shouldn't even be aware of its (non-)existence.

…but maybe you could print something about querying a remote server? That would be helpful, not just to establish the correct mental model, but also for many other issues (e.g. slow networking).

Thanks for taking a look at the server side.

[zpavlinovic]

Would that just be a message upon successful retrieval of information from the vuln db server?

I think that if we decide to add this, then we'd likely hide this under the -show verbose option. We already have people mentioning that govulncheck is quite chatty.

[gopherbot]

Change https://go.dev/cl/580175 mentions this issue: internal/scan: print progress messages only in verbose mode

[zpavlinovic]

Govulncheck first prints out the message about the user program and then goes to fetching vulnerabilities for that program. So this message would be the second one. If govulncheck hangs, then it is very likely due to the analysis taking a long time. A message on starting the request would then be misleading.

Edit: we'll just also add an additional message when the checking phase starts.

[gopherbot]

Change https://go.dev/cl/580216 mentions this issue: internal/vulncheck: emit fetch db and vuln checking progress messages

[zpavlinovic]

We looked at the server side and we believe this has something to do with replication and eventual-consistency. We could dig deeper into that, but it is not clear if it is really worth it.