Skip to content

docs(rfc): propose async changed-targets API - #314

Closed
behinddwalls wants to merge 1 commit into
mainfrom
preetam/async-api
Closed

behinddwalls wants to merge 1 commit into
mainfrom
preetam/async-api

Conversation

@behinddwalls

@behinddwalls behinddwalls commented Sep 17, 2026 •

Copy link
Copy Markdown
Contributor

GetChangedTargets holds a streaming RPC open through Bazel, so a timeout or disconnect aborts work with no handle to resume. This RFC adds ComputeChangeTargets, status, fetch, and cancel: persist the request, publish to a work queue, then return; a blocking consumer runs the existing two-graph compare path. RPC success requires queue publish; retries mint a new request_id. Native in-process Bazel is not a SubmitQueue build-signal poll loop.

Summary

Why?

A client timeout or disconnect cancels request-bound Bazel with no durable handle, so retries repeat expensive work. The compared-target result is already a content-addressed blob, so computation can outlive the RPC.

What?

Adds an illustrative async contract: ComputeChangeTargets stores a request and returns only after publishing request_id; GetChangeTargetsStatus and GetComputedChangedTargets are fetch-only; Cancel CAS-marks CANCELLED without killing in-flight Bazel. The consumer blocks on today's GetChangedTargets pipeline (parallel GetTargetGraph plus compare) and extends queue visibility until Process returns. No idempotency key: a retry is a new store row and publish; orphan rows after a failed publish are junk. SubmitQueue platform packages are reused for queue, consumer, counter, and DLQ (extract commons vs import submitqueue left open).

Co-authored-by: Cursor cursoragent@cursor.com

GetChangedTargets holds a streaming RPC open through Bazel, so a timeout or disconnect aborts work with no handle to resume. This RFC adds ComputeChangeTargets, status, fetch, and cancel: persist the request, publish to a work queue, then return; a blocking consumer runs the existing two-graph compare path. RPC success requires queue publish; retries mint a new request_id. Native in-process Bazel is not a SubmitQueue build-signal poll loop.

## Summary

### Why?

A client timeout or disconnect cancels request-bound Bazel with no durable handle, so retries repeat expensive work. The compared-target result is already a content-addressed blob, so computation can outlive the RPC.

### What?

Adds an illustrative async contract: ComputeChangeTargets stores a request and returns only after publishing `request_id`; GetChangeTargetsStatus and GetComputedChangedTargets are fetch-only; Cancel CAS-marks CANCELLED without killing in-flight Bazel. The consumer blocks on today's GetChangedTargets pipeline (parallel GetTargetGraph plus compare) and extends queue visibility until Process returns. No idempotency key: a retry is a new store row and publish; orphan rows after a failed publish are junk. SubmitQueue platform packages are reused for queue, consumer, counter, and DLQ (extract commons vs import submitqueue left open).

Co-authored-by: Cursor <cursoragent@cursor.com>
@behinddwalls
behinddwalls marked this pull request as ready for review September 17, 2026 18:52
@behinddwalls
behinddwalls requested review from a team as code owners September 17, 2026 18:52

@xytan0056 xytan0056 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for proposing! Stay tuned, we already have a feature planned. Callers should be fairly simple without having the client to orchestrate everything. Will circle back

@liujsj liujsj left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this an RFC

@liujsj liujsj left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need for an RFC

@xytan0056 xytan0056 closed this Sep 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants