Stop reporting Rego parse refusals to Sentry

Alexander Turinskerequested to merge
629577-policy-store-no-sentry-on-rego-parse-error into master

What does this MR do and why?

  • The Policy Store backend now parses every custom Rego rule on policy save and refuses a program it cannot parse (work item https://gitlab.com/gitlab-org/gitlab/-/work_items/618556). The refusal comes back as a flat string in the mutation's errors field, shaped rules[N] is invalid: <engine message> (at <line>:<column>).
  • The editor's onSave handler treated that refusal like a failed request: it showed the message in a page alert and also called Sentry.captureException.
  • Unparseable Rego is author input, not a bug, so it should not go to Sentry. Adds isRuleRegoParseError to ee/app/assets/javascripts/policy_store/utils.js and guards the existing Sentry call with it in ee/app/assets/javascripts/policy_store/components/editor/app.vue. The alert itself is unchanged.
  • The predicate matches the whole trimmed message with an anchored pattern instead of splitting on ;. RegoValidator#reported_errors joins one rule's engine errors with "; " in a single refusal, and with_compiled_rules raises on the first failing rule, so only one rules[N] is invalid: prefix can ever appear per message. Splitting on ; would send an ordinary two-typo program to Sentry.
  • A merged-program refusal (policy_rego is invalid: ..., raised by validate_merged_program! when rules parse alone but conflict once combined) is also author input but has a different shape, and it is still reported. https://gitlab.com/gitlab-org/gitlab/-/work_items/629577 notes merged-module engine faults surface as top-level GraphQL errors handled separately in https://gitlab.com/gitlab-org/gitlab/-/work_items/629203 — but a merged program that fails to parse raises a ValidationError and does reach this same handler. Worth confirming against real Sentry events before 629577 is closed.
  • Nothing that is a genuine failure is suppressed: an engine fault, a 500, a network error, or a top-level GraphQL error does not arrive as a PolicyStoreMutationError, so apiErrorMessage returns undefined and the pattern does not match.
  • Where in the editor the refusal should live, and whether the API should return a structured shape instead of a flat string, are separate open decisions on https://gitlab.com/gitlab-org/gitlab/-/work_items/629577 and are deliberately not settled here.

References

Screenshots or screen recordings

N/A — no rendered output changes. The refusal alert is unchanged; only whether the refusal is captured as an exception.

How to set up and validate locally

  1. Enable the Policy Store experiment: the instance-level policy_store_experiment_enabled application setting plus the organization setting.
  2. Go to an organization's Policy Store and create a policy with a Custom Rule (Rego) whose program does not parse, for example a body of package governance followed by deny contains msg if { then input.environment.name ==.
  3. Save. The red alert still reports rules[0] is invalid: ... and the wizard stays on the Review step.
  4. Confirm no Sentry event is produced for it (check the browser console / Sentry stub in development).
  5. Run node_modules/.bin/jest ee/spec/frontend/policy_store/utils_spec.js ee/spec/frontend/policy_store/components/editor/app_spec.js --no-coverage

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist.

Merge request reports