Repository navigation
Conversation
There was a problem hiding this comment.
Code Review
This pull request implements a fallback to route queries that cannot be executed via jobs.query through jobs.insert (createQueryJob) in createQueryArrowStream_, and adds comprehensive unit and system tests to verify this behavior. Feedback was provided to ensure type safety by guarding against an undefined job object before calling waitForJobCompletion and to use the idiomatic stream.push(null) instead of stream.end() to signal EOF.
2e029c1 to
86c5363
Compare
86c5363 to
3d6c4a9
Compare
3d6c4a9 to
799d417
Compare
799d417 to
90cb922
Compare
03aec32 to
9853b3a
Compare
9853b3a to
0bba2d3
Compare
2410242 to
d689335
Compare
d689335 to
97f41ff
Compare
97f41ff to
7539631
Compare
3469bd1 to
919d8fd
Compare
|
Rebased on the #9598/#9599 changes. Same behavior, restructured for the async flow: the |
919d8fd to
046a050
Compare
Routes queries that cannot use jobs.query (!queryReq, such as jobId, dryRun, jobTimeoutMs, or other jobs.insert-only options) through createQueryJob: - Keeps timeoutMs and jobCreationMode, which only apply to jobs.query, out of the job configuration. - Populates stream.jobReference and emits the job event once created. - Emits a single 0-row, 0-column RecordBatch immediately when dryRun is true without polling getQueryResults or calling ReadRows. - Otherwise waits for job completion via job.getQueryResults (maxResults: 0), bounded by timeoutMs like BigQuery#query, and streams Arrow batches from the anonymous default job stream (streams/_default) at offset = 0.
046a050 to
e514462
Compare
shivanee-p
left a comment
There was a problem hiding this comment.
Left a small comment, but the rest LGTM
| // Throws for an invalid request, for example a destination that isn't a | ||
| // Table, or invalid parameters. | ||
| const [job, resp] = await bq.createQueryJob(jobQuery); | ||
| if (!job) { |
There was a problem hiding this comment.
I think we need another if statement above this one with something like if (stream.destroyed) return;
There was a problem hiding this comment.
Added in f41ec7d, with a test that a stream destroyed during jobs.insert emits no job event and doesn't wait for the job.
…jobs-insert # Conflicts: # handwritten/bigquery/test/arrow.ts
Return after createQueryJob if the consumer destroyed the stream, so no 'job' event is emitted and the job isn't waited on. Stub createQueryJob with async functions in the unit tests, matching the awaited promise API. Also say in the createQueryArrowStream JSDoc that timeoutMs bounds the jobs.insert wait too and that jobs.insert queries read every row with the Storage Read API, and add system tests for timeoutMs and dryRun on the jobs.insert path.
Some query options only work with
jobs.insert(for examplejobId,destination,dryRun, orjobTimeoutMs), socreateQueryArrowStreamfailed for those queries. This runs them throughcreateQueryJobinstead.buildQueryRequest_returnsundefined(ajobs.insert-only option, orFAST_QUERY_PATH=DISABLED).timeoutMsandjobCreationModeonly apply tojobs.query, so they stay out of the job configuration;timeoutMsbounds the wait instead.stream.jobReferenceand emits thejobevent.dryRunemits one 0-row, 0-columnRecordBatchwithout waiting or callingReadRows; the job's metadata holds the dry-run statistics.streams/_defaultatoffset = 0. Errors thrown synchronously bycreateQueryJobdestroy the stream.jobs.insertruns, the stream stops without emittingjobor waiting for the job.