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
{{ message }}
This repository was archived by the owner on Mar 6, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 6, 2026. It is now read-only.
The ability to specify labels on created BigQuery jobs was supposedly added in googleapis/google-cloud-python#5654, but it doesn't work. There is also a comment in the documentation from that same PR referring to Client.update_job() which doesn't even exist.
job_config=bigquery.QueryJobConfig(labels={"app": "test"})
query_job=client.query("SELECT 1", job_config=job_config)
# no labels seen belowprint(query_job.labels)
# try and get a job later, also no labelsjob=client.get_job(query_job.job_id)
print(job.labels)
@rholloway Thanks for the report, I can confirm the reported behavior.
It turns out the labels are actually present in the raw job data, i.e. in query_job._properties["configuration"]["labels"], but the labels property tries to read them from self._properties["labels"]. If that's the only cause, it should be an easy fix.
It's worth mentioning that labels on the Table, Dataset, and Model resources are actually present an the top level of the corresponding JSON responses, while in the Job resources they are nested under the configuration dict representing a JobConfiguration resource.
@plamut I can confirm that there's a workaround by going through the job's configuration. In my case, I was able to submit a job with labels and then later access them as follows
@rarredon Indeed, semantically they represent the same thing. 👍 _configuration is a QueryJobConfig() instance, while _properties["configuration"] is the former's "raw" form (a nested dict structure).
Got an update from the backend maintainers - the labels on the jobs are immutable once a job is created, thus the client cannot update them even if it wanted to.
It still needs to read them from the correct nesting level, of course, which will be fixed soon.
Activity
plamut commentedon Jan 13, 2021
@rholloway Thanks for the report, I can confirm the reported behavior.
It turns out the labels are actually present in the raw job data, i.e. in
query_job._properties["configuration"]["labels"], but thelabelsproperty tries to read them fromself._properties["labels"]. If that's the only cause, it should be an easy fix.It's worth mentioning that labels on the Table, Dataset, and Model resources are actually present an the top level of the corresponding JSON responses, while in the Job resources they are nested under the
configurationdict representing a JobConfiguration resource.rarredon commentedon Jan 13, 2021
@plamut I can confirm that there's a workaround by going through the job's configuration. In my case, I was able to submit a job with labels and then later access them as follows
Perhaps the
_configurationattr is synonymous with_properties['configuration'], just as you found. I hope that helps.plamut commentedon Jan 13, 2021
@rarredon Indeed, semantically they represent the same thing. 👍
_configurationis aQueryJobConfig()instance, while_properties["configuration"]is the former's "raw" form (a nested dict structure).plamut commentedon Jan 14, 2021
Got an update from the backend maintainers - the labels on the jobs are immutable once a job is created, thus the client cannot update them even if it wanted to.
It still needs to read them from the correct nesting level, of course, which will be fixed soon.
[-]BigQuery: Adding labels to jobs fails to add labels[/-][+]Reading the labels set on a job fails[/+]