docs(reconcile): declare disabled users out of scope for the PlatformUser kind

[rohilsurana]

What

A disabled user does not appear in the platform-user listing the reconciler reads (the store query filters out disabled accounts), so the reconciler cannot see or manage their platform access. This documents that disabled principals are out of scope, both in the reconcile docs and as a comment on fetchCurrent.

No behavior change.

Why

This makes the existing behavior explicit so operators do not list a disabled principal and expect it to reconcile. A disabled admin is not exported and an empty file does not remove their grant. Re-enable the user first to manage their access.

Stack

Stacked on fix/reconcile-billingproduct-r2.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
frontier	Ready	Preview	Aug 19, 2026 9:47am

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 38 minutes

Limit details: You’ve used all 2 included reviews currently available.

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 within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 76e854fc-c628-4baa-bda5-f0682e741f1d

📥 Commits

Reviewing files that changed from the base of the PR and between 2c37983 and 331a656.

📒 Files selected for processing (2)

• docs/content/docs/reconcile.mdx
• internal/reconcile/platformuser_reconciler.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.}

[coveralls]

Coverage Report for CI Build 32239373931

Coverage remained the same at 48.807%

Details

• Coverage remained the same as the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	40111
Covered Lines:	19577
Line Coverage:	48.81%
Coverage Strength:	15.72 hits per line

---

💛 - Coveralls

[rohilsurana]

Review: declare disabled principals out of scope for PlatformUser

Verified on this branch: go build ./... and go test ./internal/reconcile/... pass.

For user principals, which is the reachable case, the doc is exactly right. Disabled users are filtered by notDisabledUserExp (internal/store/postgres/user_repository.go:238), so a disabled user is invisible to both fetchCurrent and Export. Since both share fetchCurrent, this is consistent with Rule 5.

Verdict: approve with nits.

Nits:

1. The prose says "disabled principals," but RFC 0001 defines a principal as a user or a service user, and the state filter exists only on the user path. serviceuser_repository.go GetByIDs has no state filter. So a disabled service user would appear in fetchCurrent, be exported, and be removed by an empty file, which is the opposite of the claim. This is latent only because there is currently no code path to disable a service user (no Disable/SetState for service users, unlike users). Either say "disabled users," or add a line that service users cannot be disabled yet.
2. Minor: this is not strictly docs-only. It also adds a 6-line comment to platformuser_reconciler.go:123-128. No executable code changes, so behavior is unaffected.

[rohilsurana]

Follow-up on the nits.

• Wording: done. Changed "disabled principals" to "disabled users" and added a line that service users cannot be disabled today, so they are always listed. The state filter only exists on the user path, so the note now matches what the code actually does.
• Not strictly docs-only: intentional. The six-line comment sits at fetchCurrent so the scope decision is visible at the code site. There is no executable change, so behavior is the same.

[rohilsurana]

Re-review (head 345417c)

Build and tests are green. The over-generalization is fixed. The note now scopes the guarantee to users and correctly adds that service users cannot be disabled today, so they are always listed. Every claim checks out against the code: notDisabledUserExp filters disabled users out of the listing, and there is no disable path for service users, so they are never filtered.

One optional consistency nit: the fetchCurrent code comment (internal/reconcile/platformuser_reconciler.go:123-128) still says "principals" where the doc now says "users". Not wrong, just less precise than the doc. Not blocking.

Verdict: approve with nits.