test_sync_query_w_dml has num_dml_affected_rows unset

[dhermes]

See: https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/2753

@tswast Any idea what would cause this "flake" to happen? (Note that the 2.7 system tests in the same build did not have this failure, as well as every other time this test case has run on CI.)

[tswast]

Bah! No clue. I wish we logged the Job ID so that I could pass it on to the backend team to investigate further.

[dhermes]

Are the job IDs generated by the client? If yes, they probably match some specific regex with the build ID in it.

[tswast]

They are in this case, but I didn't think to make them match any specific pattern. https://github.com/GoogleCloudPlatform/google-cloud-python/blob/f034c6121dabfb20cb1cf6b6ae6985b236bfef11/bigquery/google/cloud/bigquery/dbapi/cursor.py#L136

[dhermes]

Nice find. Is it worth making it possible to pass in a job_id (so the system test callers can use something unique)?

[tswast]

It doesn't fit the DB-API, but yeah I think we need to have some way to introspect.

[dhermes]

Another failure: https://circleci.com/gh/GoogleCloudPlatform/google-cloud-python/2825

[tswast]

I'll update those tests to set a job ID prefix so it'll be easier to track down.

[tswast]

Ah, one thing it could be is the load job may not have finished. I'll use our handy new Futures API to wait until they are done before doing the DML query.

[tswast]

The other thing to keep in mind is that I'd very much like to remove the sync query method. Hopefully you got my redesign proposal doc?

[lukesneeringer]

I did, but we are in fix-it week so I will not read it until Monday.

[tswast]

Unfortunately the query verb doesn't take a job ID, so we'll only be able to debug half the flakes (DB-API, but not sync query). I'll finish my PR for the DB-API part, though.

[tswast]

Closing, as I haven't seen this flake on the bigquery-b2 branch and #4245 is now out to merge that to master.