When a dependency tree of a project is too large, you may find that snyk monitor may fail. Snyk is actively working on improving performance for large dependency trees; however, there are instances where although snyk test will work, snyk monitor may fail.
snyk testshould not fail due to big tree issues for all pkg-managers except NPM/YARN (except some extreme cases where the CLI dies with out-of-memory errors). If it is failing, please log a case and include an output of snyk test -d
- all other commands may fail while posting to the backend, and a big-tree issue can be identified by running the command in debug mode with
-d, looking for:
- The request may simply time out.
- Error 413 - the project's dependency payload is too big, a symptom of "big tree"
- Error 422 - there were too many vulnerable paths, a symptom of "big tree"
- Error 502 - might so big that it killed a Registry pod, a possible symptom of "big tree"
snyk request body size: <size in bytes>- sizes above 5 MBs are considered big-trees but tend to fail above 30MB, the higher the size - more like it’s the issue In logz.io some big-trees errors can be identified by looking for errors that look like the ones you get with
type:prod AND kubernetes.container_name:registry AND "Too many vulnerable paths"
- in other (hopefully rare) cases pods will die before a useful error - so should look for hints for dying pods, like a 5xx from phoenix, in example:
type:prod AND kubernetes.container_name:registry AND msg:"Failed on phoenix api call" AND err.code:>=500
The solution - Prune dependency trees
If you are facing this error you can use the next flag --prune-repeated-subdependencies with snyk with monitor OR snyk test.
Prune dependency trees, removing duplicate sub-dependencies.
Will still find all vulnerabilities, but potentially not all of the vulnerable paths.