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

Inconsistent runtime type check of "initial" argument in graph.reachable and graph.reachable_paths #4951

Closed
anderseknert opened this issue Jul 29, 2022 · 2 comments · Fixed by #4956
Labels

Comments

@anderseknert
Copy link
Member

The graph.reachable and graph.reachable_paths built-in functions seem to behave differently from other built-in functions at runtime, as providing an unsupported type as the second argument (the "initial" value) does not cause an undefined result, and does not render a runtime error with --strict-builtin-errors provided. The declared type of the initial argument is either a set or an array, but this is never checked in the code.

echo '{"initial": 1}' |  opa eval -f pretty -I 'graph.reachable({}, input.initial)'
[]

❯ echo '{"initial": 1}' |  opa eval -f pretty --strict-builtin-errors -I 'graph.reachable({}, input.initial)'
[]

Other built-ins return either undefined on runtime type check failures, or an error if strict built-in errors is requested, e.g:

echo '{"initial": 1}' |  opa eval -f pretty -I 'lower(input.initial)'
undefined

❯ echo '{"initial": 1}' |  opa eval -f pretty --strict-builtin-errors -I 'lower(input.initial)'
1 error occurred: lower(input.initial): eval_type_error: lower: operand 1 must be string but got number

Discovered when porting these built-ins for Jarl, and while only a minor inconsistency/inconvenience in OPA, the runtime type checker there currently verifies the type of the arguments against the types declared for any given built-in in the plan definition. Fixing this here seems like the better option compared to hard coding a workaround for these two functions in any IR implementation.

@philipaconrad
Copy link
Contributor

@anderseknert This behavior seems to be caused by the implementation of the reachable and reachable_paths functions in topdown/reachable only checking if supported types are available, and then skipping action on things that don't match up type-wise, instead of giving a useful runtime type error.

@philipaconrad
Copy link
Contributor

Do we want to have errors for wrong types on both arguments? I'll have a PR up shortly with that behavior, and if we want to switch it back to returning an empty set sometimes for backwards compatibility, it'll be a simple commit or two to revert back.

philipaconrad added a commit that referenced this issue Aug 2, 2022
This commit ensures that the `graph.reachable` and `graph.reachable_paths` builtins check the types of both of their operands, and return type errors instead of default values if a wrong type is provided.

Fixes #4951
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants