Under the covers, the resources returned by synchronous jobs/query API and the follow-on jobs/getQueryResults API obscure most information found in the underlying jobs resource for the query job.

I'm up against this issue while trying to implement Client.list_jobs, which calls the jobs/list API and tries to return instances of the appropriate job class. That API call returns job resources for synchronous queries which are effectively indistinguishable from those created for asynchronous queries (I've only been able to tell them apart by checking that the datasetId of the destinationTable does not match any of the "public" datasets for the project).

Because of this discrepancy, I believe that the current jobs.RunSyncQueryJob class is misnamed: instead, it should be called something like query.QueryResults: this new/renamed class would not pretend to be a job, but instead would have a job accessor which created/returned a jobs.QueryJob instance (which would be renamed from the current jobs.RunAsyncQueryJob). Client.list_jobs would then always return instances of jobs.QueryJob, even for synchronous queries.

@dhermes, @jgeewax please comment if you disagree with this conclusion.