Skill: run on BigQuery
When to use
The executor.resource field of an Attested Computation points here when the computation's runtime is bigquery.
Preconditions
- Caller has a service account with
bigquery.jobs.createon the concept'sresourceproject. - Caller has read access on every table referenced by the computation's
# Computationfence (or the file atcomputation:). - The concept declares its
parameters:list. Every required parameter has been supplied a value by the caller.
Steps
-
Load the computation. Read the
# Computationfence from the concept body, or the file atcomputation:if the field is set. The result is a SQL string containing@name-style bind variables for each declared parameter. -
Bind parameters. Pass the caller-supplied values as BigQuery named query parameters. Do NOT string-interpolate; the attester will reject a receipt whose
executed_sqlshows literal substitution. -
Submit the job. Use
jobs.query(orjobs.insertwith aQueryconfiguration). SetuseLegacySql: false. Set the job'slabelsto includeokf_concept: <bundle-relative-path>for auditability. -
Wait for completion. Poll
jobs.getuntilstatus.state = 'DONE'. Ifstatus.errorResultis present, return the receipt withresult: nullanderror: <errorResult>so the attester can distinguish "sanctioned SQL that failed at runtime" from "the executor ran the wrong SQL." -
Assemble the receipt. Return exactly the fields declared in
executor.receipt. For this skill:{ "job_id": "bq://<project>/us/<jobId>", "executed_sql": "<queryConfig.query with parameters shown as @name>", "result": "<the first result row's cell values, in declared select-order>" } -
Never modify the computation. If the caller-supplied parameters cannot be bound (missing required, wrong type), refuse and return an error receipt. Do NOT rewrite the SQL to work around missing parameters.
Post-conditions
The receipt is handed to the concept's attester.resource. Do not display the value to the user until the attester returns verdict: ok.