Skip to content

Language Validation

No due date 36% complete

Currently we have validation logic in Language for Java and JS, and in OpenFGA for Go

The result is that our validation is inconsistent between the IDE and the Server, and we keep getting bug reports on wrong validation for one or the other.

Considering Language already is set up for multi-language consistent tests, we believe that extending support to ad…

Currently we have validation logic in Language for Java and JS, and in OpenFGA for Go

The result is that our validation is inconsistent between the IDE and the Server, and we keep getting bug reports on wrong validation for one or the other.

Considering Language already is set up for multi-language consistent tests, we believe that extending support to add semantic validation in Go and having language replace the model validation logic that the server uses is the way to go for better consistency and testability.

What that means:

  • Language will export functions to validate tuples, types, IDs, objects, users and relations. One exported, VS Code, CLI, IntelliJ, Playground, Dashboard and the core OpenFGA server will switch to using these for validating tuples, types and more (#226)
  • Store Validation will move to language (for consistent validation between VS Code, IntelliJ and the CLI), VS Code and CLI will switch to using that (#278)
  • The tests for model validation will be copied over from the server to Language, any missing gaps will need to be addressed (#181, #158, #99, #279, #52, #259, #244, #68)
  • We will need to run Language validation on existing models to ensure that we're not accidentally marking something that should be valid as invalid
  • Work will need to be done on optimizing our validation logic (#290)
  • Eventually Language should be the one responsible for exposing the type system, it would load a model and expose all sorts of helpful functionality on it such as getting terminal types on a relation, optimizing the relation definitions for server execution, getting the modules in a model (#281, #284) and more
  • Document all validation errors thrown by language (#19)
Loading