Anders Eknert

Yep, like it or not, I think we'll have to accept that `1 == 1.0` 😄 Let's just make it _consistently_ so. When creating the issue I thought this was...

We just recently made this exact change for the various `x.is_valid` [functions](https://github.com/open-policy-agent/opa/issues/4760), so having the same behavior here would be consistent with that. Unless there's a strong reason to treat...

Looking at the [policy reference](https://www.openpolicyagent.org/docs/latest/policy-reference/#types) for `is_number` I'm reminded that there's a whole bunch of other `is_x` functions too. If we do change something here it should probably not be...

It would be nice if this could use the same kind of logic for dealing with undefined as the upcoming `print` function, so that assertions failing on undefined values would...

If anyone is looking for this before it's solved in OPA, I wrote a little [test assertion library](https://github.com/anderseknert/rego-test-assertions) to help with this some time back.

Oh, `test-eqexpr-0571.yaml` seems to contain another case where `opa deps` fails to identify a dependency (`data.a`): ```rego package generated p { data.a[i] = x i = 2 } ``` ```shell...

Hi @TweeZz 👋 And thanks for submitting this. That the `print` function uses the logging system when OPA is started as a server should not be taken to mean that...

Hey again! 😃 > Using print somewhere in the code adds an entry in the decision logs like so: {"decision-id":"5aca73ce-a437-4dec-8a24-e287f7566f69","level":"info","msg":"./policies.rego:218: some useful log entry here","time":"2022-05-12T08:15:29Z"} That is not a decision...

> We are required by our Product & Solution Security Expert to mask out certain parts of the input. One of those being /input/attributes/request/http/headers as we do not want to...

Just circling back on this, did you find some time to look into decision logging yet, @TweeZz ?