[pull] master from cube-js:master - #672
Merged
Merged
Conversation
…ss (#11580) decompress ^4.2.1 carries a critical advisory (arbitrary file write via path traversal) and reached every Cube install through a chain with exactly one requirer at each hop: cubejs-backend-native -> @cubejs-infra/post-installer@^0.0.7 -> @cubejs-backend/shared@0.33.20 -> decompress@^4.2.1 `^0.0.7` is a caret on a 0.0.x version, i.e. exactly 0.0.7, and shared was pinned exactly too, so nothing could float past it. post-installer 0.1.2 repins shared to a release that dropped decompress; `^0.1.2` spans >=0.1.2 <0.2.0 and can reach it. Lockfile regenerated against the published 0.1.2: decompress@^4.2.1 and @cubejs-backend/shared@0.33.20 both gone (only decompress-response remains, an unrelated got dependency). The new @octokit/* entries are expected — post-installer gained github_artifact:// support via octokit in 0.1.0, which the old ^0.0.7 pin predated. Behaviour verified against this package's own resources config (plain host+path, not github_artifact://): 0.0.7, 0.1.1 and the published 0.1.2 all exit 0 and construct the identical native-<platform>-<arch>-<libc>-<libpython>.tar.gz URL. The node >=20 floor post-installer now declares is already this package's own. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
…re handover (#11581) * docs(byoc): tell customers to create the RDS service-linked role before handover A real BYOC provisioning run failed on this. Creating the AI Engineer RDS instance in a customer account returned: InvalidParameterValue: Unable to create the resource. Verify that you have permission to create service linked role. Amazon RDS needs `AWSServiceRoleForRDS` to exist in the account. AWS normally creates it on the customer's first database — but during BYOC provisioning that moment arrives under the `CubeCloudBYOC` role instead, and if that role cannot create it, the failure names a *parameter* rather than a permission, which sends whoever is debugging it looking in the wrong place entirely. Adds a Warning to Prerequisites with the one-off command, the "already taken" response that means there is nothing to do, and an explanation of why the grant being present in the policy is not the same as it being effective in the account (older policy version, or SCPs restricting IAM writes). Also fixes the root cause of that customer's failure: the legacy `docs/content/.../byoc/aws/deployment.mdx` policy conditions `iam:CreateServiceLinkedRole` on eks / eks-nodegroup / eks-fargate only, with no `rds.amazonaws.com` — while the current docs-mintlify page does include it. Any account provisioned from the legacy page therefore holds a role that cannot create the RDS service-linked role, which is exactly the failure above. The two policies now agree. * docs(byoc): scope the RDS callout to SCPs, and stop editing the deprecated tree Review feedback, all three correct. Reverted the `/docs` edit. The repo's CLAUDE.md is explicit — "`/docs` is the legacy docs site and is deprecated — do NOT add or edit content there" — and I edited it anyway, having read the provenance argument as a reason to override a rule rather than a reason to raise it. `cube.dev/docs/...` 308s to `docs.cube.dev/...`, so no customer would ever have read that line; it bought provenance only, at the cost of the rule. The real remediation for accounts holding the old policy is a one-off command delivered through support, which no docs edit reaches. Rewrote the callout. It was ~30 lines — longer than the Prerequisites section it interrupts — and worse, it led with an imperative and only revealed four paragraphs later that the policy on that same page already grants `rds.amazonaws.com`, so a correctly-provisioned account is unaffected. A new customer, the only audience for this page, would have read a mandatory-sounding step and then learned it did not apply to them. Now the applicability condition leads (restrictive SCPs), the grant is stated up front, and the command is the closing action. 23 lines. `organisations` -> `organizations`; it was the only British spelling under docs-mintlify/. * docs(byoc): give the SCP-denied reader a next step Review feedback, and correct. Scoping the callout to SCPs left a hole exactly where it matters: SCPs bind every principal in the account including the customer's own admin and root, so if the org genuinely denies iam:CreateServiceLinkedRole then the diagnostic command fails for the reader too. A 'has been taken' response was a clean all-clear, but AccessDenied / explicit deny in a service control policy dead-ended the one reader this warning exists for. Adds the closing sentence: the same denial will block Cube during provisioning, so the fix is amending the SCP (or excluding the account's OU), not re-running the command.
* fix(cube-cli): follow the API's items + pageInfo list shape
The public REST API standardized list responses on `items` + `pageInfo`,
keeping `data`/`count`/`pagination` only as deprecated aliases, and gave
every list endpoint `first`/`after`.
`cube environments list --offset/--limit` silently ignored both flags as
a result: the endpoint assembles its list in memory, so `items` is the
cursor page (the whole list unless `first` is passed) while only the
deprecated `data` is offset-sliced — and the CLI reads `items` first.
Read `data` when the caller uses offset paging, and reject combining the
two styles rather than printing a page nobody asked for. `attributes
list` had the same silent-ignore path (the server takes the cursor path
whenever `first`/`after` is set), so it gets the same guard.
`data-model files`/`get` read the deprecated `data` field directly;
switch them to `output::items` so they survive its removal. Deployment
versions already dropped `data` for `items`-only — that one worked
because `output::items` prefers `items`, and is now covered by a test.
Adopt `first`/`after` on the commands whose endpoints gained them:
deployments versions, environments list/tokens, variables list,
attributes list, regions, github installations/repos/branches, and
data-model branches. `--offset`/`--limit` stay, marked deprecated.
Not adopted for `logs`: the page is sliced from the start, so `--first N`
would return the oldest N lines rather than the newest. `deployments
list` and `reports list` already get a clear 400 when paging styles are
mixed, so they keep relying on the server for that.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(cube-cli): make the deprecated-field read strict, and uniform
Review follow-ups on the items + pageInfo change.
The requested envelope field is now strict. Falling back to `items` when
`data` is absent reintroduced the very bug the fix exists for: the day an
endpoint drops its deprecated `data`, `--limit 5` would have quietly
printed the whole cursor page again. It now fails pointing at
`--first/--after`.
`environments tokens` and `attributes list` read the selected field too,
instead of only validating the flags. Both page in the database, so
`items` and `data` hold the same rows and the choice is a no-op today —
but going through the same path as `environments list` removes an
asymmetry that read as an oversight, and means the strict check covers
them when `data` goes away. The reason each endpoint is in the group it
is now sits in a comment at the call site.
`offset_paging(bool, bool)` took two same-typed positional bools that
silently inverted the result if transposed. It is now `paging_field`,
taking the four flags in declaration order and returning the field to
render, so the whole decision — validate, then choose — is one tested
function rather than an untested `then_some` at each call site.
`tree_nodes` reads `list_field` rather than `items`: only a real array of
roots is a tree, and `items`' catch-all arm would hand back an envelope
carrying neither array as a lone node, rendering one blank row where
"No results" is the honest answer.
Also relabel `--offset`/`--limit` on `deployments list` and `--limit`/
`--page` on `reports list` as deprecated, which the first commit did for
`environments` and `attributes` but missed for the two commands that
already accepted `--first`/`--after`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(cube-cli): route every offset-paged list through paging_field
Second review round.
`deployments list` and `reports list` had their flags relabeled
deprecated but still rendered through plain `print_list`, so they never
reached the field selection the other four got. Checked both against the
server: each pages in the database — deployments returns
`{items: serialized, data: serialized}` and reports `{items: data, data}`
— so `items` was already the right rows and this is a no-op today, same
as environment tokens and user attributes. Routing them through
`paging_field` anyway is the point: none of the six can now quietly stop
honoring the flags when its `data` is removed. The per-endpoint reason
is a comment at each call site, and the mixed-flag error arrives without
a round-trip to a server that would have rejected it anyway.
`paging_field` takes the deprecated flag names, because `reports list`
deprecates `--limit`/`--page` rather than `--offset`/`--limit` and an
error naming the wrong flags is worse than a generic one.
`print_list` no longer discards a `Result` on a comment-enforced
invariant: rendering is split into `render`, which both entry points
feed — `print_list` with `items(response)`, `print_list_from` with
`rows_from(response, key)?`. There is no longer a `Result` to swallow.
One deliberate behavior change that fell out: `print_list_from` resolves
the key before checking `--json`, so a caller whose flags can no longer
be honored gets the error in both modes. Raw passthrough still governs
the response body; it isn't a licence to answer a page nobody asked for.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(cube-cli): pick the rendered field per endpoint, not uniformly
Third review round, reverting the blanket selection from 077cf9a.
Reading `data` everywhere "for uniformity" was wrong, and worse than
the asymmetry it replaced. Four of the five offset-paged commands slice
in the database, so their `items` already holds exactly the requested
page — and keeps holding it after `data` is removed. Selecting `data`
there is correct today and a hard error tomorrow, because `rows_from`
bails on a missing key: `cube deployments list --limit 5` would fail on
an endpoint that still honors `--limit` server-side and still returns
precisely the right rows. That trades a future no-op for a future
outage, to guard a failure mode those four cannot have. `items` can
only silently stop honoring the flags where it is the *unsliced* cursor
page, which is `environments list` alone.
So the choice is per endpoint, and now says so in the types. A
`ListPaging` const at each call site records the shape verified against
the server — `OFFSET_LIMIT_IN_QUERY`, `LIMIT_PAGE_IN_QUERY`,
`OFFSET_LIMIT_DATA_ONLY` — and only the `data_only` one renders `data`.
That keeps the asymmetry deliberate and legible rather than accidental,
which was the round-one objection, without the round-two overcorrection.
Validation stays uniform: no command may mix the two paging styles.
The consts also carry the deprecated flag names, so the free-form label
repeated at five call sites is gone and a future `--page` rename has one
place to update. Renamed `first_deprecated`/`second_deprecated`, which
read as "the deprecated form of --first" next to the real `first`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
github-actions
Bot
added
pr:community
rust
data source driver
cubejs-jdbc-driver
driver:athena
driver:bigquery
driver:clickhouse
driver:crate
driver:databricks
driver:dremio
driver:druid
driver:duckdb
driver:firebolt
driver:hive
driver:materialize
driver:mongodb
driver:mssql
driver:mysql
driver:mysql-aurora-serverless
driver:oracle
driver:pinot
driver:postgres
labels
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )