test: assert SNYK-POLICY-0001 for an unparseable .snyk file [OSF-495]

[MoisBrigitte]

Pull Request Submission Checklist

• Follows CONTRIBUTING guidelines
• Commit messages are release-note ready, emphasizing what was changed, not how.
• Includes detailed description of changes
• Contains risk assessment (Low | Medium | High)
• Highlights breaking API changes (if applicable) — none
• Links to automated tests covering new functionality
• Includes manual testing instructions (if necessary)
• Updates relevant GitBook documentation (PR link: n/a)
• Includes product update to be announced in the next stable release notes

What does this PR do?

Adds an acceptance test pinning the CLI-side behaviour of snyk/cli-extension-os-flows#285, and bumps cli-extension-os-flows to the commit that carries it.

When snyk test runs against a project whose .snyk policy file cannot be parsed, the unified test API path now reports it through the error catalog as SNYK-POLICY-0001 ("Unable to apply a policy with an invalid configuration") with a message naming the file and the specific problem, instead of surfacing it as an unspecified SNYK-CLI-0000.

The fixture uses the shape that prompted OSF-495 — a .snyk whose ignore metadata is indented level with the dependency path instead of under it:

ignore:
  SNYK-JS-LODASH-590103:
    - '*':
      reason: None Given
      expires: 2021-11-21T21:55:08.466Z

The legacy TS CLI loaded this file, but silently ignored the misplaced fields — so the ignore never applied and users had no indication why. The new behaviour fails loudly.

Rendered output the test asserts against:

 ERROR   Unable to apply a policy with an invalid configuration (SNYK-POLICY-0001)

           The policy file '.../with-malformed-snyk-file/.snyk' could not be read:
           invalid .snyk policy: line 8: dependency path 'reason' must map to a set
           of ignore settings, but it is scalar "None Given"; check the indentation.
           Please correct the file, or run the command without it.

Status:  422 Unprocessable Entity
Docs:    https://docs.snyk.io/scan-with-snyk/error-catalog#snyk-policy-0001

Changes:

• cliv2/go.mod, cliv2-private/go.mod — bump cli-extension-os-flows to v0.0.0-20260912170847-6551ffa27241 (via gomodsync).
• test/fixtures/npm/with-malformed-snyk-file/ — new fixture, copied from npm/with-vulnnerable-lodash-and-snyk-file with an unparseable .snyk.
• test/jest/acceptance/snyk-test/snyk-test-malformed-policy-file.spec.ts — new acceptance test.

Where should the reviewer start?

test/jest/acceptance/snyk-test/snyk-test-malformed-policy-file.spec.ts, then the fixture's .snyk.

Beyond the catalog code, the test asserts that the message stays readable: it must not contain SNYK-CLI-0000, and must not leak the Go types behind the parser (localpolicy., struct {) — an earlier iteration dumped the whole Rule struct literal at the user three times over.

The test normalizes whitespace before matching, because the error renderer word-wraps and pads the box.

How should this be manually tested?

make build BUILD_MODE=private

TEST_SNYK_COMMAND=./binary-releases/snyk-macos-arm64 npx jest --runInBand test/jest/acceptance/snyk-test/snyk-test-malformed-policy-file.spec.ts

Verified locally as fail-before/pass-after with two real builds:

cli-extension-os-flows pin	output	test
ad447d86c87d (before the fix)	SNYK-CLI-0000 + Go struct dump	fails
6551ffa27241 (this PR)	SNYK-POLICY-0001, clean message	passes

One local-environment caveat: on a machine where getFirstIPv4Address() resolves to a VPN address, the Go binary cannot reach the fake server and falls back to legacycli. Substituting 127.0.0.1 for fakeServerIp works around it locally; the committed spec keeps getFirstIPv4Address() for consistency with the sibling specs in that directory.

What's the product update that needs to be communicated to CLI users?

An unparseable .snyk policy file is now reported as a specific, actionable error (SNYK-POLICY-0001) naming the file and the problem, rather than as a generic failure. Note the behaviour change: a .snyk whose ignore metadata is misindented used to be accepted and silently ignored, and now fails the command. This is gated behind the internal_snyk_cli_use_unified_test_api_for_os_cli_test feature flag.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.