docs: document undocumented customer-facing changes from recent releases

[keydunov]

Check List

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

Description of Changes Made

Routine sweep cross-checking recent shipped changes in cube-js/cube and cubedevinc/cubejs-enterprise against docs-mintlify, filtered against the customer-facing criteria used for this kind of sweep. Three small, genuinely undocumented items:

• CubeStore query-planning concurrency limits (reference/configuration/environment-variables.mdx): documents the new CUBESTORE_MAX_CONCURRENT_QUERY_PLANS and CUBESTORE_MAX_QUEUED_QUERY_PLANS env vars (feat(cubestore): Limit how many logical plans are built at once #11924), which bound how many query plans CubeStore builds at once and reject rather than queue indefinitely once the wait list is full.
• Google Sheets / Excel add-in — opening a spreadsheet shared with you (docs/integrations/google-sheets.mdx, docs/integrations/microsoft-excel.mdx): documents that the add-in now lists every Cube-backed placement in a shared document, including ones you don't have access to (shown with only their location and who to ask, never the exploration name/data) — previously such placements were silently invisible (cubejs-enterprise#15253).
• Unsafe single-brace {SECURITY_CONTEXT...} in YAML models (docs/data-modeling/concepts/syntax.mdx): adds a warning that the plain {reference} syntax is resolved once at compile time (and can be reused across different users' requests on dedicated infrastructure), so SECURITY_CONTEXT must use Jinja's {{ }} form instead — matching a new Semantic Model IDE lint warning shipped for the same footgun (cubejs-enterprise#14852).

Verified none of these were already covered by the three prior "undocumented Cube Cloud features" sweep PRs, and confirmed no new broken links/anchors via npx mintlify broken-links --check-anchors.

Two larger candidates surfaced by the same sweep — cross-deployment workbook promotion, and the Cube Cloud console navigation redesign — need dedicated new docs pages rather than a small patch, so they're being filed as tickets instead of included here.

🤖 Generated with Claude Code

https://claude.ai/code/session_012faGgHoPfu6QR1kSP2jHF9

---

Generated by Claude Code

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
cubed3	🟢 Ready	View Preview	Sep 22, 2026, 12:19 AM

💡 Tip: Enable Automations to automatically generate PRs for you.

[claude]

Claude finished @keydunov's task in 3m 46s —— View job

---

Changes requested — 1 high, 1 medium, 2 low. The SECURITY_CONTEXT warning states the mechanism backwards.

Full review

• Read PR diff and the changed files in full
• Verify CUBESTORE_MAX_*_QUERY_PLANS against the CubeStore Rust source
• Verify new link anchors resolve
• Check the {SECURITY_CONTEXT} claim against schema-compiler behavior
• Handle prior review threads
• Post inline findings

High — docs/data-modeling/concepts/syntax.mdx:887-896

{SECURITY_CONTEXT.field} in a YAML sql field is resolved per request, not at compile time: YamlCompiler.ts:232 wraps the string into an arrow function, CubeSymbols.ts:1414 lifts SECURITY_CONTEXT into a parameter, and BaseQuery.js:5298 supplies it per query. Jinja is the compile-time one — {{ }} renders the model source once per context_to_app_id key, the property reference/data-modeling/context-variables.mdx:831 already warns about for COMPILE_CONTEXT — and SECURITY_CONTEXT is not a variable Cube exposes to Jinja at all. As written the warning moves users from a per-request value to a per-compile one, and flags the sql: example directly above it as unsafe when it isn't.

The underlying footgun looks real but narrower: {...} in a YAML property outside transpiledFieldsPatterns (title, description, meta, …) takes the compile-time f-string path at YamlCompiler.ts:271-279. Worth confirming against cubejs-enterprise#14852 which positions the IDE lint flags, and scoping the warning to those.

Medium — reference/configuration/environment-variables.mdx:2126-2134

CUBESTORE_MAX_QUEUED_QUERY_PLANS=0 disables the queue limit (planning_throttle.rs:99, doc comment at :28), so a user setting 0 to mean "never queue" gets an unbounded wait list. "A valid number" doesn't cover it; suggestion posted inline.

Low

• environment-variables.mdx:2109-2114 — "wait briefly for a slot" omits that the wait is capped at CUBESTORE_QUERY_TIMEOUT (120s) and the query then fails with a user-visible error (planning_throttle.rs:67-92). Also: auto is max(4, 2 * cores) (config/mod.rs:1402-1407), and an unparseable value warns and falls back to auto rather than erroring (config/mod.rs:1421-1429).
• docs/data-modeling/concepts/syntax.mdx:1015 — link text "dedicated infrastructure" vs. the target heading "Single-tenant infrastructure" (admin/deployment/infrastructure.mdx:42).

Not verifiable here

The Google Sheets / Excel shared-document sections describe enterprise add-in behavior (cubejs-enterprise#15253) with no counterpart in this repo — reviewed for wording only. Both pages carry identical text, which is consistent with how the two integration pages already mirror each other.

Review threads

The listing returned 0 of my own threads — no prior threads, so nothing resolved and nothing re-affirmed. All four findings posted fresh.

· branch `claude/gallant-ramanujan-wfyi9d`

[claude]

The warning states the mechanism backwards for the syntax the section it sits in documents, and prescribes a form that is more compile-time bound, not less.

{SECURITY_CONTEXT.field} in a YAML sql (or sql_table, or any pattern in transpiledFieldsPatterns) is not resolved at compile time. YamlCompiler.transpileYaml wraps those strings into an arrow function (packages/cubejs-schema-compiler/src/compiler/YamlCompiler.ts:232), CubeSymbols.resolveSymbol recognises SECURITY_CONTEXT as a context symbol and lifts it into a function parameter (packages/cubejs-schema-compiler/src/compiler/CubeSymbols.ts:1414, CONTEXT_SYMBOLS at :268), and the argument is supplied per query from BaseQuery (packages/cubejs-schema-compiler/src/adapter/BaseQuery.js:5298 → MemberSqlTemplateCompiler.compileMemberSql, whose header notes "SECURITY_CONTEXT is resolved eagerly here against the provided context"). BaseQuery is constructed per request, so the value is the requesting user's.

Jinja goes the other way: {{ }} renders the model source before compilation, i.e. once per context_to_app_id key — the same "evaluated only once" property reference/data-modeling/context-variables.mdx:831 already warns about for COMPILE_CONTEXT. So {{ SECURITY_CONTEXT.field }} is not "re-evaluated for every request"; and SECURITY_CONTEXT is not among the variables Cube exposes to Jinja (docs/data-modeling/dynamic/jinja.mdx never mentions it — the documented request-context entry point there is COMPILE_CONTEXT). Following this advice, a user moves a per-request value to a per-compile one.

The footgun the lint is presumably about is real but narrower: a {...} reference in a YAML property outside transpiledFieldsPatterns (title, description, meta, …) takes the f-string path at YamlCompiler.ts:271-279, which is not wrapped in an arrow function and is evaluated during compilation.

Please confirm against cubejs-enterprise#14852 which positions the IDE lint actually flags, and scope the warning to those — as written it tells users the sql: example immediately above it is unsafe when it isn't.

Also worth reconsidering the recommendation target: SECURITY_CONTEXT is documented as deprecated (reference/data-modeling/context-variables.mdx:863), so steering people toward a new spelling of it needs a note.

[claude]

0 disables the queue limit entirely, and the table's "A valid number" hides that. PlanningThrottle only enforces the cap when max_queued != 0 (rust/cubestore/cubestore/src/queryplanner/planning_throttle.rs:99, doc comment at :28: "max_concurrent or max_queued of 0 disables the respective limit"). A user who reads this page and sets CUBESTORE_MAX_QUEUED_QUERY_PLANS=0 intending "never queue, reject immediately" gets the opposite — an unbounded wait list.

Suggested change

	The maximum number of queries that may wait for a query planning slot (see
	[`CUBESTORE_MAX_CONCURRENT_QUERY_PLANS`](#cubestore_max_concurrent_query_plans)
	above). Once this many queries are already waiting, further queries are
	rejected immediately instead of being queued indefinitely.
	| Possible Values | Default in Development | Default in Production |
	| ---------------- | ---------------------- | --------------------- |
	| A valid number | `5000` | `5000` |
	## `CUBESTORE_MAX_QUEUED_QUERY_PLANS`
	The maximum number of queries that may wait for a query planning slot (see
	[`CUBESTORE_MAX_CONCURRENT_QUERY_PLANS`](#cubestore_max_concurrent_query_plans)
	above). Once this many queries are already waiting, further queries are
	rejected immediately instead of being queued. Set to `0` to disable the limit,
	i.e., allow an unbounded number of waiting queries.
	| Possible Values | Default in Development | Default in Production |
	| ------------------------- | ---------------------- | --------------------- |
	| `0` or a positive integer | `5000` | `5000` |

[claude]

"the rest wait briefly for a slot instead" understates the failure mode: the wait is capped at CUBESTORE_QUERY_TIMEOUT (120s by default), and a query that exceeds it fails with a user-visible error rather than eventually planning —

Waited longer than 120 s for a query planning slot. Please consider using a
multi-router Cube Store deployment, or increasing the number of clusters if you
already use one.

(rust/cubestore/cubestore/src/queryplanner/planning_throttle.rs:67-69 for the timeout, :84-92 for the message; the duration comes from config.query_timeout() at queryplanner/mod.rs:296.)

Since this is the operator-facing page someone lands on after seeing that error, worth saying that queries can be rejected by the timeout as well as by the queue cap, and linking CUBESTORE_QUERY_TIMEOUT.

Two smaller points on this entry:

• The auto note is accurate but vague — it resolves to max(4, 2 * cores) (rust/cubestore/cubestore/src/config/mod.rs:1402-1407), deliberately oversubscribed because planning also waits on the metastore. Giving the formula lets an operator reason about an override.
• A non-numeric, non-auto value isn't an error: it logs a warning and falls back to auto (config/mod.rs:1421-1429). Not required, but it's the kind of thing this page usually states.

[claude]

Link text says "dedicated infrastructure" but the target heading is "Single-tenant infrastructure" (docs-mintlify/admin/deployment/infrastructure.mdx:42, where #dedicated-infrastructure survives only as an explicit {#...} anchor). Other pages that link here use the current name — e.g. admin/deployment/maintenance-window.mdx:10. Worth matching so the warning doesn't reintroduce the retired term.