Experimental Optimized ListObjects - Known Issues

[rhamzeh]

This issue thread is to summarize and provide the community a single place to collect issues & feedback they find with the new Experimental ListObjects, which we can then turn into issues on the openfga/openfga repo as the team verifies them and works through them.

---

ListObjects

We do have multiple issues with ListObjects

I. The current default experimental ListObjects implementation

This version just calls check in parallel underneath the hood, it was rolled out so that the community can provide feedback on the API while we work on a proper scalable version.

Known issues:

• Does not preform well at scale (the more relationships to check for, the longer the response)
• Returns just the data found by the time it hits the limit, there are two limits: time (config: listObjectsDeadline) and amount (config: listObjectsMaxResults). For OpenFGA they default to 3s and 1000 results respectively. If any of these are hit, OpenFGA will return the results it has found so far and close the connection. You can try increasing these values if you are not getting all the results.
• This version is very taxing to the database due to the sheer amount of checks it runs.
• This version currently loads all the necessary data into memory before starting to call checks on them instead of streaming them from the database, which can be very taxing to the memory. This is a known issue with this version that we decided not to work on fixing as we want to focus on building the optimized ListObjects endpoint and replacing this one.

II. The new optimized experimental ListObjects

This version aims to solve the scaling issues of the initial version and should return more complete results much faster than the initial version, but requires schema 1.1 and is turned off by default unless you turn it on via the experimentals config.

Known issues:

• Throws an error in models where and and but not are used (resolved by falling back to the non-optimized version)
• Does not resolve and and but not in the optimized version (drastically increasing latency and open DB threads when they are present)
• Does not handle Type-bound Public Access/Typed Wildcard (e.g. *, user:*, etc..) (may be fixed by: fix: add typed wildcard support to ListObjects openfga#444)
• Does not evaluate rewrites on usersets (reported by Fede on Discord) (may be fixed by: fix: reverse expand computed_userset targets and non-assignable relations properly openfga#432)
• Can return invalid results in some cases
• Still has some scaling issues on OpenFGA, especially with Postgres

---

Configuration

• Configuring OpenFGA
  • Enabling Experimental Features such as Optimized ListObjects
• Configuration Schema

[rhamzeh]

Optimized ListObjects does not evaluate rewrites on usersets

(reported by Fede on Discord)

Given the following schema

model
  schema 1.1

type team
  relations
    define admin: [user]
    define member: [user,team#member] or admin

type trial
  relations
    define editor: [user,team#member] or owner
    define owner: [user]
    define viewer: [user,team#member] or editor

Steps to reproduce:

1. write 500 trials as (user="team:DEVS#member", relation="editor", object="trial:<id>")
2. write the tuple (user="user:fede", relation="admin", object="team:DEVS")
3. call check (user="user:fede", relation="viewer", object="trial:<id>") // true, confirming user:fede has access
4. call optimized_list_objects (user="user:fede", relation="viewer", object="trial") // returns an empty list
5. write the tuple (user="user:fede", relation="member", object="team:DEVS") // optimized_list_objects now works fine and returns the 500 trials, meaning that the optimized_list_objects was not evaluating the rewrite on team:DEVS#member