test: migrate TestCRUD off subject IDs

[alnr]

What

TestCRUD in cmd/cloudx/relationtuples fails against Ory Network:

rpc error: code = InvalidArgument
desc = subject_id is not supported; please migrate to subject sets

The tuples it writes now use subject sets.

Scope of the rejection

I probed this before changing anything — it is not a data-shape quirk in the test:

subject	namespace	result
"s" (plain string)	legacy (id: 0)	rejected
UUID	legacy	rejected
user:alice	legacy	rejected
"s"	OPL (update opl)	rejected
subject set	legacy	accepted

So writing a subject_id is refused unconditionally, under both namespace kinds.

The dropped assertion

ory is allowed s r n o1 is removed rather than adapted, because the command itself no longer works against Ory Network. It takes a plain subject and sends it as a subject_id, so the check is rejected with the same error:

Warning: passing namespace and object as separate arguments is deprecated. …
Could not make request: rpc error: code = InvalidArgument
  desc = subject_id is not supported; please migrate to subject sets

And no reachable configuration makes it answer true: a subject-set tuple grants access to the members of a set, membership can only be expressed by a tuple whose subject is a plain ID, and that is exactly what is refused. Every permission chain has to terminate in a subject ID.

Asserting {"allowed":false} would have encoded a broken command as expected behaviour, so the test records what happened in a comment instead. ory is allowed being unusable against Ory Network looks like a real CLI bug and wants its own issue — flagging rather than filing, since the right fix depends on whether the server change is intended.

Why this is separate

This failure predates the branch it was found on and is unrelated to it. It was invisible because the rate limiting fixed in #457 killed relationtuples in TestMain before TestCRUD ever ran, which is why it shows up in only some of master's red runs.

CI here is expected to stay red until #457 lands — master's browser login is rate limited, and the packages that fail on that have nothing to do with this change. Verified locally instead: TestCRUD passes, and so does the whole relationtuples package (34s).

🤖 Generated with Claude Code

https://claude.ai/code/session_01Tg5VWFUb7824qkrooUdvBA

[coderabbitai]

Warning

Review limit reached

@alnr, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 34 minutes

Limit details: You’ve used all 1 included review currently available under your plan.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: a9b266a0-b697-4579-b8e7-692bf6c6dc77

📥 Commits

Reviewing files that changed from the base of the PR and between d34a356 and 8d08d7f.

📒 Files selected for processing (1)

• cmd/cloudx/relationtuples/relationtuples_test.go

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[alnr]

Folded back into #457 so the two land together and one PR can go green.

Split out, neither PR could pass on its own: #457 unmasks this subject_id failure by fixing the login, and this branch sat on a master whose browser login is still rate limited. They were only ever verified green together.

#457 also carries a real fix for ory is allowed now, which this PR only flagged. Correcting what I wrote here: the command is not unusable — keto's ParseSubject reads anything containing a colon as a subject set, so ory is allowed 'n:s#r' r n:o1 works. What was broken is the CLI's own usage line, which advertised only the deprecated four-argument form and never mentioned subject sets, steering callers into the one spelling the server rejects.

Branch fix/keto-subject-sets is left in place; delete it whenever.