Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Only a single issue reported by opa check --strict #5815

Open
anderseknert opened this issue Apr 5, 2023 · 1 comment
Open

Only a single issue reported by opa check --strict #5815

anderseknert opened this issue Apr 5, 2023 · 1 comment

Comments

@anderseknert
Copy link
Member

Given the following policy:

package p

import data.foo
import data.foo

a := any([foo])

I would expect opa check --strict to report two violations — the shadowing of an import, and the use of the deprecated any function. However, only the first encountered error seems to be reported:

❯ opa check --strict p.rego
1 error occurred: p.rego:4: rego_compile_error: import must not shadow import data.foo

Removing the shadowing and now the compiler will flag the deprecated function:

❯ opa check --strict p.rego
1 error occurred: p.rego:5: rego_type_error: deprecated built-in function calls in expression: any

Using multiple deprecated functions seem to flag all of them:

❯ opa check --strict p.rego
2 errors occurred:
p.rego:5: rego_type_error: deprecated built-in function calls in expression: any
p.rego:6: rego_type_error: deprecated built-in function calls in expression: all

But introducting another violation in the policy, and we're back to reporting only one:

package p

import data.foo

a := any([foo])
b := all([true])

f(x) {
    input.foo
}
❯ opa check --strict p.rego
1 error occurred: p.rego:8: rego_compile_error: unused argument x

Expected behavior is that all violations up to the value of --max-errors (default 10) are reported.

@anderseknert
Copy link
Member Author

From a cursory look: the compiler is "hardcoded" to bail out after any given compilation step with errors. What is collected as errors are thus only the errors from a single compilation step, and not the compilation as a whole — strict mode or not.

@johanfylling mentioned that it could be problematic to continue after a failed compilation step, as then you could get cascading errors caused by errors in previous compilation steps. From what I can see, this should not be the case for the strictness checks, so perhaps they could be run / reported separately. There is however no separation of those from the other steps, nor a distinct type used for those kind of errors.

Not going to work on this, just thought it could be useful for someone who do later 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

1 participant