Relation tuples checking error

[Rudkovskiy427]

I am using Ory Keto v0.12.0-alpha.0 to implement the following relationships in a service:
User1 is a member of Group1; Group1 has the editors relation to Document1.
Therefore, User1 should be able to edit Document1.

The problem is that, periodically, when checking User1's permissions using the GET relation-tuples/check endpoint:

{
  "namespace": "docs",
  "relation": "edit",
  "subject": "user1_uuid",
  "object": "document1_uuid"
}

the response returns allowed=false instead of true. Notably, for some time, the check returns true as expected, and then, unexpectedly, it starts returning false—indicating the user no longer has permission to edit the document—but then it goes back to normal, and the user regains access.

During all this, the relationships between User1, Group1, and Document1 do not change. Reviewing the logs provided no insight—what I saw were just the responses to the relation-tuples/check requests.

Please advise what might be causing this issue and where to look. I'd like to note that all relationships between the entities are correctly set, yet the user's access occasionally disappears.

[vinckr]

Hello @Rudkovskiy427

can you please share the steps to reproduce this on a fresh install?

if the relationships do not change the response should be consistent.

Reviewing the logs provided no insight—what I saw were just the responses to the relation-tuples/check requests.

So Keto always responded as expected or was there flaky behaviour? it sounds like it might be a bug in permission handling in your app rather than a flaky response from Keto?

[GitNimay]

This sounds more like an operational or consistency issue than a modeling issue, assuming the tuples and namespace config are really unchanged.

The first thing I would check is whether every Keto instance is using the exact same database and the exact same namespace configuration. Intermittent allowed=false often happens when requests are load balanced across instances where one instance has stale config, points at another database, or has not been restarted after a namespace config change.

For this model, the tuples should look conceptually like this:

groups:Group1#members@user1_uuid
docs:Document1#editors@(groups:Group1#members)

And the permission check should be against the computed permission relation, for example:

{
  "namespace": "docs",
  "object": "document1_uuid",
  "relation": "edit",
  "subject_id": "user1_uuid"
}

The namespace config must explicitly connect edit to editors, and editors must allow the group subject set. If edit is not defined as a computed relation from editors, then the check may only work in cases where there is a direct edit tuple.

I would investigate in this order:

1. Confirm the exact tuples during a false result

When the check returns false, immediately list the relevant tuples from the same Keto instance:

keto relation-tuple list

or query the read API for:

groups:Group1#members@user1_uuid
docs:Document1#editors@(groups:Group1#members)

If the tuple is missing only sometimes, that points to database, replication, or instance routing.

2. Check load balancing

If you run multiple Keto pods or containers, temporarily pin traffic to one instance. If the problem disappears, compare:

Keto version
namespace config
database DSN
migration status
read/write endpoint routing
environment variables

across all instances.

3. Increase check depth

Group based permissions require subject set expansion. If your real graph is deeper than the simplified example, pass an explicit max-depth on the check request.

GET /relation-tuples/check?...&max-depth=10

If increasing depth fixes it, the issue is graph traversal depth, not tuple storage.

4. Turn on debug logs around the check path

Normal access logs will not show why expansion failed. Enable more verbose logs and look specifically for expansion depth, subject set traversal, or storage errors.

5. Be cautious with v0.12.0-alpha.0

That version is very old and alpha. If this is production or production like, I would strongly recommend testing on a current supported Keto or Ory Permissions release. There have been many changes since that alpha series, and intermittent authorization behavior is not something I would try to debug long term on an alpha build.

So the likely causes are:

1. Requests hitting different Keto instances with different config or storage
2. Read/write database inconsistency or replica lag
3. Namespace relation not modeling edit through editors correctly
4. Subject set expansion depth or width limits
5. A bug in the old alpha version

I would start by pinning to one Keto instance and checking the tuple list at the exact moment allowed=false is returned. That will tell you whether the tuple is disappearing from Keto’s view, or whether the tuple exists but expansion/check logic is failing.