Conversation
tgroh
left a comment
tgroh
left a comment
There was a problem hiding this comment.
"We'll throw" means the client (the one the user is submitting the pipeline from), yes? If so, can probably be reworded to either "The client will throw" or "Throws"
|
|
||
| package org.apache.beam.runner_api.v1; | ||
|
|
||
| option java_package = "org.apache.beam.common.job"; |
There was a problem hiding this comment.
Our existing protobuf naming is consistent in versioning the java package (with v1)
| // Cancel the job | ||
| rpc cancel (CancelJobRequest) returns (CancelJobResponse) {} | ||
|
|
||
| // Subscribe to a stream of state changes of the job |
There was a problem hiding this comment.
"... of the job. Will immediately return the current state of the job as the first response.", or some other similar verbage (assuming this is what is done; otherwise note that the current state will not be returned, and getState should be used instead)
|
|
||
| // Submit is a synchronus request that returns a jobId back | ||
| // GRPC will throw a GRPC_STATUS_UNAVAILABLE if server is down | ||
| // We'll throw an error with code ALREADY_EXISTS if the jobName is reused |
There was a problem hiding this comment.
Document the restrictions of that parameter, including "Runners are permitted to (blah blah blah)"
| } | ||
|
|
||
| message SubmitJobResponse { | ||
| string jobId = 1; // (required) |
There was a problem hiding this comment.
Document how this differs from jobName; potentially something like "used to refer to the submitted job in all future calls"
| } | ||
|
|
||
| message CancelJobResponse { | ||
| JobState.JobStateType state = 1; // (required) |
There was a problem hiding this comment.
Are there any restrictions to what this can be? Any terminal state or CANCELLING seems like a reasonable restriction
|
|
||
|
|
||
|
|
||
| // Cancel is a synchronus request that returns a jobState back |
There was a problem hiding this comment.
Are there restrictions on when cancel can be called and will not throw an error?
There was a problem hiding this comment.
Not sure yet as I think Dataflow just doesn't say anything if you click cancel twice.
|
|
||
| package org.apache.beam.runner_api.v1; | ||
|
|
||
| option java_package = "org.apache.beam.common.job"; |
| // Cancel the job | ||
| rpc cancel (CancelJobRequest) returns (CancelJobResponse) {} | ||
|
|
||
| // Subscribe to a stream of state changes of the job |
|
|
||
| // Submit is a synchronus request that returns a jobId back | ||
| // GRPC will throw a GRPC_STATUS_UNAVAILABLE if server is down | ||
| // We'll throw an error with code ALREADY_EXISTS if the jobName is reused |
| } | ||
|
|
||
| message CancelJobResponse { | ||
| JobState.JobStateType state = 1; // (required) |
|
|
||
|
|
||
|
|
||
| // Cancel is a synchronus request that returns a jobState back |
There was a problem hiding this comment.
Not sure yet as I think Dataflow just doesn't say anything if you click cancel twice.
| } | ||
|
|
||
| message SubmitJobResponse { | ||
| string jobId = 1; // (required) |
3 participants
Follow this checklist to help us incorporate your contribution quickly and easily:
[BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replaceBEAM-XXXwith the appropriate JIRA issue.mvn clean verifyto make sure basic checks pass. A more thorough check will be performed on your pull request automatically.R: @tgroh PTAL
This is part 1 of many for the job submission API. Currently experimental so might evolve a bit as we make progress.