fix(frontend): invalidate revoked active roles in existing sessions

[Lundomn]

What type of PR is this?

• API-change
• BUG
• Improvement
• Documentation
• Feature
• Test and CI
• Code Refactoring

Which issue(s) this PR fixes:

Fixes #27650

What this PR does / why we need it:

REVOKE role FROM user clears the privilege cache, but an already-active session could refill that cache while continuing to authorize through the revoked active role and its older transaction snapshot. This change:

• caches and revalidates the active user-role grant together with the session privilege cache generation;
• reads active-role membership in a private pessimistic RC transaction with a locking catalog read, and applies the same RC semantics to role revocation;
• refreshes active-role membership synchronously at the explicit clear_privilege_cache boundary;
• performs that validation before privilege-cache hits and before owner or grant-option fallback paths;
• keeps built-in roles compatible and marks a successfully selected role as valid;
• returns catalog errors without caching them, so transient failures remain retryable;
• adds focused unit/race coverage and a 42-statement multi-session BVT for existing/new sessions, prepared statements, transaction boundaries, role switching, error paths, and regrant recovery.

Validation on commit 4e2be0b0eae7576bf291b5be928c45a0d2e6b1de (based on origin/main 424fe3d821e45fe883ab93af5b404d77686d05a0):

• mo-cgo-test -count=1 -coverprofile=frontend-cover.out ./pkg/frontend/...
• mo-cgo-test -race -count=1 ./pkg/frontend/...
• seven focused authorization/cache tests with -race -count=7
• go vet -mod=readonly ./pkg/frontend/...
• make config
• make err-check
• git diff --check
• mo-tester BVT: 10 consecutive runs, 42/42 statements, 100%
• local real-server E2E covering revoke and regrant behavior

The new helper functions have 80%-100% function coverage; the main changed authorization/revoke functions are above the repository's 75% threshold.

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[CLAassistant]

All committers have signed the CLA.

[XuPeng-SH]

Deep re-review of exact head 37bd6fb.

The prior blockers are closed:

• active-role membership is published only after the private transaction commits successfully;
• authorization uses a non-locking latest-committed RC read, avoiding same-user serialization;
• built-in role identity is tenant-aware, including sys-tenant custom role ID 2;
• cache generation prevents an old validation from repopulating after invalidation;
• cache OFF -> SET ROLE -> REVOKE -> ON now invalidates the stale decision before caching resumes.

I reviewed all production and test hunks, authorization fallbacks, role switching, prepared execution, session migration/cache-mode boundaries, transaction cleanup, and Q1-Q3 lifecycle/liveness/boundedness. The cache remains one bounded atomic entry, every private background transaction reaches finishTxn and Close, and no new unbounded wait or hot-path lock was introduced.

Exact-head CI is green, including frontend UT/coverage and standalone/compose BVT. The focused unit/race cases and public multi-session BVT cover committed revoke, old user transactions, prepared statements, cache-disabled mode, regrant, catalog/commit failures, and stale-generation races. No blocking correctness, performance, security-boundary, or unhappy-path issue remains.

[aptend]

Deep re-review of exact head 37bd6fb. I read all historical reviews, inline comments, thread state, and issue #27650; compared the rebased patch series and the increment since my 110175b review; and rechecked the complete diff. The prior sys-tenant role-ID, transaction-publication, non-locking-read, and cache-mode blockers are materially closed. The new OFF→SET ROLE→REVOKE→ON fix both avoids publishing membership while caching is disabled and invalidates on every session cache-mode assignment; migration boundaries also invalidate. Q1-Q3 audit found one bounded atomic membership entry, complete transaction/BackgroundExec cleanup, generation-safe invalidation, and no added lock/wait cycle. Exact-head full frontend tests, focused race tests (three runs), go vet, and diff checks pass; exact-head CI, including frontend UT/coverage and standalone/compose BVT, is green. No blocking correctness, security, lifecycle, concurrency, or performance issue remains.

[mergify]

Merge Queue Status

• ✅ Entered queue — 2026-08-28 10:26 UTC · Rule: main · triggered by rule Automatic queue on approval for main
• 🟠 Checks running · in-place
• 🚫 Left the queue — 2026-08-28 11:59 UTC · at 79fbe481c5233304aeda0043e5ad13d96097bb9a

This pull request spent 1 hour 33 minutes 29 seconds in the queue, with no time running CI.

Waiting for any of

• check-neutral = Matrixone CI / UT Test on Ubuntu/x86
• check-skipped = Matrixone CI / UT Test on Ubuntu/x86
• check-success = Matrixone CI / UT Test on Ubuntu/x86

All conditions

• any of [🛡 GitHub branch protection]:
  • check-neutral = Matrixone CI / UT Test on Ubuntu/x86
  • check-skipped = Matrixone CI / UT Test on Ubuntu/x86
  • check-success = Matrixone CI / UT Test on Ubuntu/x86
• #review-threads-unresolved = 0 [🛡 GitHub branch protection]
  • fix(frontend): invalidate revoked active roles in existing sessions #27737
• github-review-approved [🛡 GitHub branch protection]
  • fix(frontend): invalidate revoked active roles in existing sessions #27737
• any of [🛡 GitHub branch protection]:
  • check-success = Matrixone CI / SCA Test on Linux/arm64
  • check-neutral = Matrixone CI / SCA Test on Linux/arm64
  • check-skipped = Matrixone CI / SCA Test on Linux/arm64
• any of [🛡 GitHub branch protection]:
  • check-success = Matrixone Compose CI / multi cn e2e bvt test docker compose(PROXY)
  • check-neutral = Matrixone Compose CI / multi cn e2e bvt test docker compose(PROXY)
  • check-skipped = Matrixone Compose CI / multi cn e2e bvt test docker compose(PROXY)
• any of [🛡 GitHub branch protection]:
  • check-success = Matrixone Utils CI / Coverage
  • check-neutral = Matrixone Utils CI / Coverage
  • check-skipped = Matrixone Utils CI / Coverage
• any of [🛡 GitHub branch protection]:
  • check-success = Matrixone UT Coverage / UT Coverage on Ubuntu/x86
  • check-neutral = Matrixone UT Coverage / UT Coverage on Ubuntu/x86
  • check-skipped = Matrixone UT Coverage / UT Coverage on Ubuntu/x86
• any of [🛡 GitHub branch protection]:
  • check-success = Matrixone Standlone CI / multi CN e2e BVT Test on Linux/x64(COMPOSE, PESSIMISTIC)
  • check-neutral = Matrixone Standlone CI / multi CN e2e BVT Test on Linux/x64(COMPOSE, PESSIMISTIC)
  • check-skipped = Matrixone Standlone CI / multi CN e2e BVT Test on Linux/x64(COMPOSE, PESSIMISTIC)

Reason

Pull request #27737 has been dequeued

Pull request from fork cannot be queued. This pull request comes from a fork, and Mergify needs the author's permission to update its branch.

The author needs to enable "Allow edits from maintainers" on this pull request.

Failing checks:

• 🟠 Matrixone CI / UT Test on Ubuntu/x86 (job log)

Hint

You should look at the reason for the failure and decide if the pull request needs to be fixed or if you want to requeue it.
If you do update this pull request, it will automatically be requeued once the queue conditions match again.
If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio queue comment.

Tick the box to put this pull request back in the merge queue (same as @mergifyio queue).

• Requeue this pull request