fix: cached GraphQL schema can result in missing members if used with access policies

[paveltiunov]

Check List

• Tests have been run in packages where changes have been made if available
• Linter has been run for changed code
• Tests for the changes have been added if not covered yet
• Docs have been added / updated if required

Issue Reference this PR resolves

Addresses the GraphQL schema caching issue causing intermittent 400s when different security contexts share a CompilerApi instance.

Description of Changes Made

Problem

The GraphQL schema was previously built from RBAC-filtered metadata and cached per CompilerApi instance. When multiple users with different RBAC roles shared the same CompilerApi (via contextToAppId), the first user's RBAC-filtered schema got cached and used for ALL users — causing intermittent 400 errors for fields that should be accessible.

The branch igor/core-384-investigate-graphql-schema-caching-causing-intermittent-400s proposed adding JS-side member validation in graphql.ts before calling load(). However, this validation is redundant because the Rust-side result transform layer can perform this check.

Solution

Instead of adding JS-side validation, this PR fixes the existing Rust-side validation in query_result_transform.rs to properly handle RBAC-denied members even when query results are empty.

Root cause of the Rust-side gap: When RBAC denies access, applyRowLevelSecurity adds a 1=0 filter that returns zero rows. With zero rows, QueryResult::from_js_raw_data produces empty columns. The Rust get_members() function previously short-circuited on db_data.columns.is_empty() without checking if requested members were actually accessible in the annotation.

Changes:

1. query_result_transform.rs (Rust):

   • Extracted ensure_member_in_annotation() to deduplicate the hidden member check that was previously copy-pasted in get_members, get_vanilla_row, and the new validation function
   • Added validate_query_members_in_annotation() that checks the query's measures, dimensions, and time dimensions against the annotation map even when db_data.columns is empty (segments are excluded since the annotation map only contains measures, dimensions, and time dimensions)
   • Used ensure_member_in_annotation() in all three check sites

2. gateway.ts: Build GraphQL schema from unfiltered metadata (skipVisibilityPatch: true) so it can be safely cached across all security contexts sharing a CompilerApi.

3. CompilerApi.ts: Added skipVisibilityPatch option to metaConfig() to bypass RBAC visibility patching when building the shared GraphQL schema.

4. Integration test: Added smoke-rbac-graphql.test.ts with test fixtures verifying:

   • All roles see the same unfiltered GraphQL schema (schema is properly shared)
   • RBAC-denied members return "You requested hidden member" errors at query time
   • Different roles get appropriate access
   • Complete denial (includes: []) blocks all member access

5. CI: Added smoke:rbac-graphql to CI pipeline.

6. Updated existing tests: smoke-rbac.test.ts tests that previously expected silent empty results for hidden members now correctly expect "You requested hidden member" errors.

How RBAC enforcement works end-to-end

1. load() fetches metaConfig() with RBAC visibility patching → hidden members get isVisible: false
2. filterVisibleItemsInMeta() strips items where isVisible === false
3. prepareAnnotation() builds annotation from filtered metadata → hidden members are not in the annotation
4. Rust's TransformedData::transform calls get_members which:
   • For non-empty results: checks each column's member against annotation via ensure_member_in_annotation
   • For empty results (RBAC denial with 1=0): calls validate_query_members_in_annotation to check the query's requested members
5. If a member is missing from annotation → ensure_member_in_annotation throws "You requested hidden member" error
6. Error propagates: Rust → getFinalResult() reject → handleError → GraphQL error response

  

[codecov]

Codecov Report

❌ Patch coverage is 14.28571% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 57.88%. Comparing base (515eeae) to head (a8f6707).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
...ackages/cubejs-server-core/src/core/CompilerApi.ts	16.66%	5 Missing ⚠️
packages/cubejs-api-gateway/src/gateway.ts	0.00%	1 Missing ⚠️

❗ There is a different number of reports uploaded between BASE (515eeae) and HEAD (a8f6707). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (515eeae)	HEAD (a8f6707)
cubesql	1	0

Additional details and impacted files

@@             Coverage Diff             @@
##           master   #10590       +/-   ##
===========================================
- Coverage   78.58%   57.88%   -20.71%     
===========================================
  Files         475      225      -250     
  Lines       92822    17581    -75241     
  Branches     3612     3614        +2     
===========================================
- Hits        72945    10176    -62769     
+ Misses      19333     6861    -12472     
  Partials      544      544               

Flag	Coverage Δ
cube-backend	57.88% <14.28%> (-0.01%)	⬇️
cubesql	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.