You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(bigquery): refuse a padded projectId instead of silently resolving it
Guarding these paths introduced a data-loss hazard that the guard itself hid.
projectId was interpolated as encodeURIComponent(params.projectId) before this
branch — never trimmed — so ' my-project ' became %20%20my-project%20%20,
which names no GCP project and failed cleanly:
before: /bigquery/v2/projects/%20%20my-project%20%20/datasets/prod_dataset
after: /bigquery/v2/projects/my-project/datasets/prod_dataset
safeUrlPathSegment trims, so on delete_dataset and delete_table that turns a
request which did nothing into one that irreversibly destroys a real dataset or
table, from a value the caller never wrote.
The rule applied is narrow and testable: this change must not turn a failing
request into a succeeding one. Every identifier it newly began trimming now
refuses surrounding whitespace — projectId in all eleven tools, plus datasetId
and tableId where those were previously untrimmed. Identifiers already trimmed
before this branch keep safeUrlPathSegment, since trimming them is not a change
made here and refusing them would break callers whose stored value works today.
Rejection is not argued from consistency with the other guarded sites; that
averages over very different blast radii. It stands on two facts specific to
these values: no legitimate BigQuery identifier carries surrounding whitespace,
so nothing real is refused, and the previous behaviour was already a clean
failure, so refusing preserves it while naming the offending parameter.
Pinned by a REJECTS-style set that upgrades the generic per-pair whitespace
assertion to demand a throw, plus explicit delete-tool tests. Verified
non-vacuous: reverting either guard to a plain trim fails both.
0 commit comments