[zvonand]

Closes #1032

Changelog category (leave one):

• Improvement

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Added profiles_mapping to the token user directory to map OAuth groups to settings profiles, which take precedence over profiles from roles.

CI/CD Options

Exclude tests:

• Fast test
• Integration Tests
• Stateless tests
• Stateful tests
• Unit tests
• Performance tests
• Aarch64 tests
• All with ASAN
• All with TSAN
• All with MSAN
• All with UBSAN
• All with Coverage
• All Regression
• Disable CI Cache

Regression jobs to run:

• Fast suites (mostly <1h)
• Aggregate Functions (2h)
• Alter (1.5h)
• Benchmark (30m)
• CAS (content-addressed storage; Antalya only)
• ClickHouse Keeper (1h)
• Iceberg (2h)
• LDAP (1h)
• OAuth (5m)
• Parquet (1.5h)
• RBAC (1.5h)
• SSL Server (1h)
• S3 (2h)
• S3 Export (2h)
• Swarms (30m)
• Tiered Storage (2h)

[github-actions]

Workflow [PR], commit [7da0019]

[zvonand]

@blau-ai

[zvonand]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-25T09:33:43.956705Z	e62d0c3	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[blau-ai]

CI triage

Verdict: 2 failing checks, both pre-existing on antalya-26.8 — neither is caused by this PR. Everything else in the run is skipping/green (this run only executed the two regression suites below; builds, stateless and integration were skipped/cached, so the new test_token_profiles_mapping integration test did not run here).

Check	Classification	PR-caused?
Regression release oauth / RegressionTestsRelease / OAuth / oauth	Regression-suite expectation bug (pre-existing)	No
Regression release swarms / RegressionTestsRelease / Swarms / swarms	Flaky/infra, distributed (pre-existing)	No

---

1. OAuth regression — pre-existing suite bug (500 vs 403)

All OAuth failures (/oauth, /oauth/access control, /oauth/groups) share one root cause. The suite asserts a denied query returns HTTP 500, but the server correctly returns HTTP 403:

Expected HTTP status code 500, but got 403. Response body:
Code: 497. DB::Exception: a_977c6e: Not enough privileges. To execute this query,
it's necessary to have the grant CREATE TEMPORARY TABLE ON *.*. (ACCESS_DENIED)

The query is correctly denied — this is the right, secure behavior. ACCESS_DENIED (497) maps to HTTP_FORBIDDEN (403) in core ClickHouse (src/Server/HTTP/exceptionCodeToHTTPStatus.cpp:83-85), which this PR does not touch. The failing scenarios (missing_default_profile_does_not_grant_unrestricted_access, group_name_matches_clickhouse_role) exercise RBAC denial, not profile assignment.

Evidence it is not this PR: the base branch antalya-26.8 (MasterCI run 39839856866, head ab9c4003, 2026-10-22 — before this PR) fails the identical scenarios with the same Expected HTTP status code 500, but got 403 message. So the mismatch exists without your change.

Suggested fix (not in this repo): the fix belongs in the clickhouse-regression suite — oauth/tests/steps/common.py::assert_query_denied and the access-control step in oauth/tests/steps/clikhouse.py should expect status_code=403 for ACCESS_DENIED (or accept both 403 and 500). I can't push that from here (it lives in the regression repo, not Altinity/ClickHouse). It is worth filing/pinging the QA owners so the OAuth suite goes green again on the branch.

2. Swarms regression — flaky/infra (pre-existing)

Failures are in cluster discovery/check cluster discovery with wrong cluster name, node failure/cpu overload, and cpu overload all swarm nodes — distributed/connection behavior under CPU load, e.g.:

Code: 279. DB::Exception: ... Cannot connect to any replica for query execution.
(ALL_CONNECTION_TRIES_FAILED)

This suite tests S3 swarm cluster discovery and node-failure resilience. This PR touches only src/Access/TokenAccessStorage.{cpp,h} and docs — zero swarm code — so it cannot be the cause. The same Swarms / swarms job also fails on the base-branch run above. Classify as pre-existing flaky/infra; safe to re-run, though it will likely stay red until the swarm-suite flakiness is addressed separately.

---

PR health check

The code change itself (profiles_mapping on the token user directory) looks self-contained: roles_mapping/profiles_mapping now share one parseGroupMapping parser, profiles are rebuilt from scratch on each login (so a profile of a left group is dropped), and default_profile is applied before mapped profiles with documented precedence. CI as run here surfaces no PR-attributable failure. The gap is that this run did not execute the new tests/integration/test_token_profiles_mapping — a full CI run (or re-trigger of the stateless/integration jobs) would be worth confirming before merge, since that's the test that actually covers this change.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e62d0c3eb2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[zvonand]

@blau-ai

[blau-ai]

CI triage — oauth-profiles PR

Verdict: 3 failing checks, none caused by this PR's code. All failures are either in unrelated test areas (Iceberg export, swarm resilience) or are a stale HTTP-status expectation in the external oauth regression suite — the OAuth access-control enforcement your change touches actually behaves correctly in every failing scenario.

Head SHA analyzed: 7da0019.

Check	Failures	Classification
Integration tests (amd_asan_ubsan, db disk, old analyzer, 5/8)	21	Pre-existing / infra — unrelated (Iceberg)
Regression release oauth	2 sub-suites	Test-expectation mismatch (not a functional regression)
Regression release swarms	3 scenarios	Flaky / infra — unrelated (distributed swarm)
PR	—	Aggregate gate (red only because of the above)

---

1. Integration tests 5/8 — NOT PR-caused

All 21 failures are in a single unrelated file, test_storage_iceberg_with_spark/test_export_partition_iceberg.py (every test_*_transform, test_identity_*, test_rejected_*, …). They all fail on the same error:

Code: 497. DB::Exception: default: Not enough privileges. To execute this query,
it's necessary to have the grant SHOW NAMED COLLECTIONS SECRETS ON s3. (ACCESS_DENIED)

This is an Iceberg/Spark + named-collection privilege setup issue and has nothing to do with src/Access/TokenAccessStorage.* or OAuth. Pre-existing / infra; safe to re-run or ignore for this PR.

2. Regression release oauth — NOT a functional regression (test needs a one-line fix)

Two sub-suites fail: /oauth/access control and /oauth/groups. Both fail on the exact same assertion, and the enforcement is actually correct:

• access control → missing_default_profile_does_not_grant_unrestricted_access (access_control.py:169)
  Expected HTTP status code 500, but got 403. … Not enough privileges … CREATE TEMPORARY TABLE ON *.*. (ACCESS_DENIED)
• groups → group_name_matches_clickhouse_role (groups.py:45 → steps/common.py:157 assert_query_denied)
  Expected HTTP status code 500, but got 403. … Not enough privileges … SELECT ON system.users. (ACCESS_DENIED)

In both cases the query was denied — which is precisely what the tests are verifying (missing profile ⇒ no unrestricted access; matched group role ⇒ no access to system.users). The only mismatch is the HTTP status: the test expects 500, the server returns 403.

That 403 is correct and is not something this PR changed: ACCESS_DENIED maps to HTTP_FORBIDDEN in src/Server/HTTP/exceptionCodeToHTTPStatus.cpp:83-85, last modified 2026-08-31 — before this branch existed. This PR touches only src/Access/TokenAccessStorage.{cpp,h} and docs; no HTTP-handler file is in the diff. The regression tests encode the old behavior where ACCESS_DENIED came back as 500.

Fix (in the clickhouse-regression repo, not here — these oauth/ tests aren't in Altinity/ClickHouse): update the expected status to 403 in

• oauth/tests/steps/common.py → assert_query_denied (status_code=500 → 403), and
• the inline call in oauth/tests/access_control.py:169.

Accepting either 403 (and ideally 500 for compat) would make these green again without changing any ClickHouse behavior.

3. Regression release swarms — NOT PR-caused

Three scenarios fail — cluster discovery/check cluster discovery with wrong cluster name, node failure/cpu overload, cpu overload all swarm nodes — all with:

Code: 279. DB::Exception: Cannot connect to any replica for query execution.
(ALL_CONNECTION_TRIES_FAILED)
(query: SELECT hostName(), count() FROM s3Cluster('swarm', 'http://minio:9000/...'))

These are distributed s3Cluster('swarm', …) resilience tests that deliberately induce CPU overload / node failure; connection timeouts under that load are classic flakiness. Entirely unrelated to OAuth/token/profile code. Flaky / infra; safe to re-run.

---

⚠️ One thing to check: your new test didn't run here

The PR adds tests/integration/test_token_profiles_mapping/, but that test does not appear anywhere in the praktika integration report — the Integration tests (amd_asan_ubsan, targeted) job (the one that runs PR-touched tests) was SKIPPED in this run, and the 8-way db disk, old analyzer split didn't pick it up either. So the feature's own integration test wasn't exercised by this CI run. Worth re-triggering the targeted integration job (or confirming the suite selection includes the new directory) so profiles_mapping is actually validated before merge.

Bottom line

Nothing in src/Access/TokenAccessStorage.* is implicated by any of these failures. The profile/group assignment logic enforces access correctly in every oauth scenario that failed. Next steps: (1) fix the two stale status_code=500 expectations in the oauth regression suite, (2) re-run swarms + integration 5/8, (3) make sure the new test_token_profiles_mapping actually runs.

🤖 Generated with Claude Code