fix: improve reliability around call graph generation - #1276
Conversation
| // Used with the Docker plugin only. Allows application scanning. | ||
| 'app-vulns'?: boolean; | ||
| reachableVulns?: boolean; | ||
| callGraphBuilderTimeout?: number; |
|
@muscar nice! how should the usage of the timeout from the user perspective should look like? |
7fb307a to
34f53d4
Compare
34f53d4 to
081577a
Compare
|
@muscar can you add screenshot on the pr description? |
081577a to
e1768aa
Compare
There was a problem hiding this comment.
I think the as as CallGraphError is not needed now, but maybe help in reading?
There was a problem hiding this comment.
Can you elaborate on the different kinds of errors? If it's a timeout error, a permissions error, or something else. Each one will have a different action the user can take before contacting us
There was a problem hiding this comment.
@orsagie We don't have enough context in the CLI right now to elaborate--because we only have a generic CallGraphError with a generic string message, and an inner error. Since string messages can change, I don't think inspecting those to glean more info is a good idea, because it leads to brittle code.
I do agree with your point that it's good to provide users with a more detailed reason for the failure so they can provide that info to support.
I see two ways of achieving this:
- Change the error message to tell them to re-run the command with
-d, and provide the output in their support query; or - Change the error message in the maven plugin to something less generic, and more error specific.
I would personally prefer the first approach as the code in the plugin doesn't have to change as new error cases appear, and we'll be getting almost the same info anyway. What do you think?
There was a problem hiding this comment.
Just noticed I didn't comment in the right place, this comment's place is after the request to registry has been made, and regards how we handle those responses.
This error handling is specifically for after a call to the plugins, and in that case I agree with point 1. I think the error from maven plugin already asks to run with -d, can you double check? might not need to change anything here.
There was a problem hiding this comment.
The maven plugin doesn't print the -d advice, but I will open a PR to make it do so.
e9fdab8 to
d64ac7f
Compare
There was a problem hiding this comment.
I see other flags have a new line after the flag
There was a problem hiding this comment.
Also, can add like others
(test and monitor command only)
There was a problem hiding this comment.
Can you write that is only available for paid users?
There was a problem hiding this comment.
I am a little uneasy about adding a flag for paid users only. In the past we have checked against feature flags, but eventually released to all. Maybe instead display an error saying something like This feature is not available for this org, please contact us if you wish to use it?
There was a problem hiding this comment.
This is static text - rather not to share this info in the help text?
There was a problem hiding this comment.
Then do it in both places. They might not be targeting the correct org?
There was a problem hiding this comment.
I thought the plan is to roll this to free users at some point, right? And we already have a feature flag which we check for, and show a message. We could change the feature flag message slightly to say that this is a paid feature only (for now)?
cc/ @orsagie @darmalovan
There was a problem hiding this comment.
--reachable-vulns-timeout=<number> ? (and new line)
There was a problem hiding this comment.
Is there a case where users want different timeouts for different cases? Consider allowing to set a longer default in the config? (maybe not for now, but in future)
There was a problem hiding this comment.
@orsagie I don't know. I think this is highly project specific, so the users are in the best position to tweak it as needed. We provide a default just because we don't want it to block their flows for too long.
There was a problem hiding this comment.
@darmalovan Because WebStorm (and typescript) complains that the value can't be a number.
d64ac7f to
d47e4b0
Compare
|
|
d47e4b0 to
8bb2c7b
Compare
3d5c805 to
8e17159
Compare
8e17159 to
97c6817
Compare
orsagie
left a comment
orsagie
left a comment
There was a problem hiding this comment.
small typo, but otherwise the changes LGTM now.
97c6817 to
907a9f7
Compare
0b4eb38 to
495e096
Compare
495e096 to
44fc1e8
Compare
|
🎉 This PR is included in version 1.364.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
6 participants
What does this PR do?
This is meant to improve the experience around reachable vulns by:
Merge after snyk/snyk-cli-interface#36 and snyk/snyk-mvn-plugin#73, and after updating the dependencies to the appropriate versions.
What are the relevant tickets?
https://snyksec.atlassian.net/browse/FLOW-336
Screenshots
Running with a timeout:
Running with a timeout and passing
-d: