5 Common Errors in Writing Rego

Learn from my mistakes!

1. You’re using the ‘if’ keyword (smart!) but you forgot to import the ‘if’ keyword.

   1. This causes subtle compilation errors that seem to be pointing at something else.

   2. If you build the rule in the Rego playground, and it works fine, but fails when you try to run it directly, this is probably why.

2. You don’t properly validate your input data

   1. If you’re assuming the input JSON has a particular schema, you can end up with things being ‘undefined’ and short-circuited when you don’t expect it

   2. I wrote a (simple) tool that accepts a schema document and creates rules from it to do this validation of the input JSON. Let me know if this would be helpful to you.

3. Your output JSON exposes some of the internal rules of your Rego

   1. Every time you create a top-level rule (or rule set) you end up with an output value that reflects the name of the rule.

   2. To avoid this, consider using functions, which aren’t exposed.

4. You’re using the ‘data’ record(s) to manage time-sensitive information in Rego

   1. When you publish a new policy/data bundle, the OPAs that are associated with that source will eventually discover it, and update their internal data to match. But there’s no guarantee how quickly it will happen. It will probably happen within a minute. That’s a risk that you’ll have to evaluate.

5. You’re not building automated tests

   1. Rego is a subtle language, and its use of declarative logic is not something that most people master quickly.

   2. To the best of your ability, you should organize your rules to make it easy to test. And then you should write the tests! Whether you use the built-in OPA tool, or a standalone tool (I’m working on one of these, lmk if this would be interesting to you), you should not become complacent about the possibilities of unexpected rule interactions leading to incorrect outcomes.

   3. For example, if you’re writing rules that validate a JWT (hard to test!) and then evaluate a policy decision on the data associated with the JWT, you should package those “families” of rules independently. Then write automated tests for the policy decisions.