fix(language): require an object on every tuple filter

[sergiught]

Description

A tuple_filters entry that set user and/or relation but left object empty used to pass mapping validation and integration save, then fail every FGA Read at runtime. FGA's Read API needs an object type (the id may be empty, the type may not), so a filter with no object can never match. The failure was worse than one broken rule: readAll returns on the first failed read, so a single object-less filter also discards the writes of unrelated valid rules that matched the same event.

This is statically detectable, so the check moves to validation. validateTupleFilters now rejects any filter with no object, names the rule and the field, and tells the author to set at least a type prefix like document:. The error surfaces from validate, test, and integration save rather than only appearing as a failed Read against a live store.

The old "at least one field set" check is replaced, not kept alongside: object-required subsumes it and the old message would now point authors in the wrong direction. The separate expect_tuple_filters matcher keeps its own "at least one field" rule, since that is a partial matcher for tests, not an FGA read.

Two shipped example mappings relied on the now-rejected pattern in their delete filters, so user.yaml and group.yaml gained an object type prefix (user:, group:) plus the matching expect_tuple_filters.

References

Review Checklist

• I have clicked on "allow edits by maintainers".
• I have added documentation for new/changed functionality in this PR or in a PR to openfga.dev [Provide a link to any relevant PRs in the references section above]
• The correct base branch is being used, if not main
• I have added tests to validate that the change in functionality is working as expected

[Copilot]

🟡 Changes recommended

Two moderate parser issues and one documentation nit remain unresolved.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR requires an object on every tuple filter and updates validation, documentation, tests, and fixtures accordingly.

Changes:

• Added object-required tuple-filter validation.
• Updated parser tests and example fixtures.
• Revised language documentation and specifications.

File summaries

File	Summary
rules_test.go	Updated tuple-filter fixtures with objects.
language/README.md	Documents the object requirement; the exported GoDoc still needs updating (nit, 2 votes).
language/parser.go	Adds validation, but field-specific diagnostic positioning and concrete object format validation need changes (moderate, 1 vote each).
language/parser_test.go	Adds tests for object-required validation.
docs/language-spec.md	Updates tuple-filter syntax and constraints.

Review details

Suppressed comments (2)

language/parser.go:523

• The new diagnostic is attached to the whole filter item rather than the missing field: Field points at .object, but Position resolves filterLookup without the .object suffix. This makes source-aware consumers highlight the list entry instead of the object field; use the same field-specific lookup as the other tuple-field validations.

				Position: nodePosition(resolveNodePath(root, filterLookup)),

language/parser.go:519

• This only checks that the YAML value is non-empty, so a static filter such as object: org (or object: 123) still compiles even though it has no type:id object type and will be rejected when the consumer sends the Read request. The new contract and error text say the value must provide at least an object type prefix; please validate concrete object values against that format (and add a regression test), while retaining a separate path for dynamic templates.

		if f.Object == "" {

• Files reviewed: 5/5 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.