docs: Snowflake cancellation, KPI block styling, filter operators, Python-on-dashboards - #11454
docs: Snowflake cancellation, KPI block styling, filter operators, Python-on-dashboards#11454keydunov wants to merge 2 commits into
Conversation
…ouse query Cube-initiated cancellation (orphaned/timeout or the running-query REST endpoint) now cancels the underlying Snowflake statement via the driver's new query-cancellation support (#11428), instead of leaving it running in the warehouse.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
|
Claude finished @keydunov's task in 1m 40s —— View job Review: docs-only change, accurate — 0 high, 1 medium, 2 lowDocs-only, 10 added lines. The claim is backed by the code. Two inline comments posted (best-effort wording, anchor validity) plus one gap between the PR description and the diff. Full reviewChecklist
VerificationThe behavior described is real. One note on the PR description rather than the diff: it says the driver cancels "via Findings
Gap vs. PR descriptionThe description says the note is "cross-linked from the REST API's running-query cancellation endpoint," but Other checksSecurity, performance, and testing sections of the review checklist don't apply — no executable code changed. Frontmatter, reference-style link definitions, and root-relative internal links all follow |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| When Cube cancels a query against Snowflake — for example, an orphaned or | ||
| timed-out query, or a request cancelled through the | ||
| [`/v1/running-query/{requestId}`][ref-rest-api-cancel] REST (JSON) API | ||
| endpoint — the Snowflake driver also cancels the underlying statement, so the | ||
| warehouse stops running (and billing for) it instead of continuing in the | ||
| background. |
There was a problem hiding this comment.
Cancellation is best-effort in the implementation, but this reads as a guarantee. In SnowflakeDriver.executeCancelable / cancelStatement (packages/cubejs-snowflake-driver/src/SnowflakeDriver.ts:1058, :972):
- if the cancel is requested before the statement was issued, nothing is sent to the warehouse (the driver just rejects locally) — nothing to stop;
- the cancel ack is bounded by
CANCEL_ACK_TIMEOUT(30s) and an SDK error/timeout is only logged as a warning, then resolved — Cube does not retry or surface a failure.
Suggest softening slightly so users don't read it as a hard billing guarantee:
| When Cube cancels a query against Snowflake — for example, an orphaned or | |
| timed-out query, or a request cancelled through the | |
| [`/v1/running-query/{requestId}`][ref-rest-api-cancel] REST (JSON) API | |
| endpoint — the Snowflake driver also cancels the underlying statement, so the | |
| warehouse stops running (and billing for) it instead of continuing in the | |
| background. | |
| When Cube cancels a query against Snowflake — for example, an orphaned or | |
| timed-out query, or a request cancelled through the | |
| [`/v1/running-query/{requestId}`][ref-rest-api-cancel] REST (JSON) API | |
| endpoint — the Snowflake driver also asks Snowflake to cancel the underlying | |
| statement, so the warehouse stops running (and billing for) it instead of | |
| continuing in the background. Cancellation is best-effort: if the statement | |
| hasn't been issued yet there's nothing to cancel, and a failed or unacknowledged | |
| cancel is logged as a warning. |
| warehouse stops running (and billing for) it instead of continuing in the | ||
| background. | ||
|
|
||
| [ref-rest-api-cancel]: /reference/core-data-apis/rest-api/reference#base_path/v1/running-query/requestid |
There was a problem hiding this comment.
Worth confirming this anchor resolves in the Mintlify preview. The target heading is ## `{base_path}/v1/running-query/{requestId}` (docs-mintlify/reference/core-data-apis/rest-api/reference.mdx:470), and the #base_path/v1/running-query/requestid form is copied from the same-page links in that file (lines 29, 420) — so if those in-page anchors are already stale, this cross-page link inherits the bug and silently lands at the top of the reference page instead of the section.
…erators, and correct Python-on-dashboards behavior - KPI blocks: document the Background fill color (Number, Progress bar, Sparkline, HTML), the Neutral comparison color, and the Sparkline/Progress bar value-format override — all shipped in cubejs-enterprise#13162 and cubejs-enterprise#13113 but undocumented. - Dashboard filter widgets: add the is empty / is not empty string operators (cubejs-enterprise#13456), missing from the operators-by-dimension-type table. - Python analysis: the 'On dashboards' section was factually stale — cubejs-enterprise#13499 made dashboard Python widgets run live per viewer (like SQL widgets) instead of replaying the last saved Run. Corrected the behavior description and the row-level-security implications.
keydunov
changed the title
|
Claude finished @keydunov's task in 2m 2s —— View job Review: docs-only, 4 files — 0 high, 1 medium, 3 lowCommit Full reviewChecklist
VerifiabilityThe Snowflake claim is backed by code in this repo and I confirmed it last round ( The three new pages document Cube Cloud UI surfaces whose source is not in this repo — no KPI block, dashboard control, or Python-sandbox code exists under Findings
Also on Prior threadsBoth earlier Snowflake threads are still unresolved and still apply —
The one-way cross-link gap I raised last round also stands: Other checksSecurity / performance / testing sections of the review checklist don't apply — no executable code changed. Frontmatter, root-relative internal links, and Mintlify component usage follow MetaThe commit message and PR title/description cover only the Snowflake change. If the three Cloud UI pages are intentional, the PR description should name them so a reviewer knows to verify those claims; if they were picked up accidentally, they belong in a separate PR. |
| On dashboards, this changes: each viewer's live run applies row-level security for | ||
| **their own** identity, the same as a SQL widget — it isn't the Run author's access | ||
| persisted for everyone who views the dashboard. |
There was a problem hiding this comment.
The dashboard exception is placed after the <Warning> that it contradicts, which is the one spot in this page where a skimmed read is a security misunderstanding.
The callout above (lines 128–144) still asserts unconditionally that Python "runs with the security context of the person who pressed Run", that the result "is then persisted on the report", and that "Row-level security is applied at run time, not at view time." With this PR, none of that holds for dashboard widgets — and the callout is exactly the block a reader is most likely to read instead of the surrounding prose, not in addition to it.
Suggest scoping the warning to workbooks and pointing at the dashboard case from inside it, e.g.:
| On dashboards, this changes: each viewer's live run applies row-level security for | |
| **their own** identity, the same as a SQL widget — it isn't the Run author's access | |
| persisted for everyone who views the dashboard. | |
| On dashboards, this changes: each viewer's live run applies row-level security for | |
| **their own** identity, the same as a SQL widget — it isn't the Run author's access | |
| persisted for everyone who views the dashboard. |
…plus a one-line addition inside the <Warning> itself (outside this suggestion's range), such as "This describes Python in a workbook tab. On dashboards the widget runs live per viewer — see below." Fix this →
| | Dimension type | Operators | | ||
| |---|---| | ||
| | **String** | `is`, `is not`, `contains`, `not contains`, `starts with`, `not starts with`, `ends with`, `not ends with`, `is null`, `is not null` | | ||
| | **String** | `is`, `is not`, `contains`, `not contains`, `starts with`, `not starts with`, `ends with`, `not ends with`, `is empty`, `is not empty`, `is null`, `is not null` | |
There was a problem hiding this comment.
Two follow-ups on adding is empty / is not empty next to is null / is not null:
- The row now offers four operators whose difference (empty string vs. SQL
NULL) is the whole reason both pairs exist, but the page doesn't say which is which. One clause under the table — e.g. "is emptymatches empty strings;is nullmatches missing values" — saves a support round-trip. reference/data-modeling/view.mdx:372lists the operator labels forfilter_barand prefaces them with "what you see in the filter bar is what you type" — that list omitsis empty/is not empty. If these labels also exist in the workbook filter bar (and not only in dashboard control widgets), that reference list is now incomplete and should get the same two entries.
| | Setting | Description | | ||
| |---|---| | ||
| | **Background** | Fill color for the block | | ||
|
|
There was a problem hiding this comment.
**Background** | Fill color for the block is now repeated in four of the six block tables, and this HTML table exists only to carry that one row. The Text block (line 89) still has no settings table at all — so a reader can't tell whether Text has no Background or whether it was just missed.
If Background is universal across block types, a single line under ## Block types ("Every block type has a Background setting that sets the block's fill color.") is both shorter and answers the Text question. If Text genuinely lacks it, worth saying so explicitly. Fix this →
2 participants
Check List
Description of Changes Made
A batch of small documentation gaps found by cross-checking recent shipped changes against docs-mintlify:
/v1/running-query/{requestId}endpoint) now cancels the underlying Snowflake statement so the warehouse stops billing for it. Added a short note to the Snowflake data source page.is empty/is not emptyoperators (cubejs-enterprise #13456): first-class value-less operators for string dimensions, distinct from the null checks. Added to the filter widget's operators-by-dimension-type table.