-
-
Notifications
You must be signed in to change notification settings - Fork 4
feat: add explicit SUBSCRIBE message to initiate subscriptions #122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR introduces protocol versioning and an explicit subscription model for the incremental build protocol. The changes enable clients to negotiate protocol versions and explicitly subscribe to specific watch types (sources or runfiles).
Key changes:
- Adds protocol version negotiation with support for version 0 (legacy) and version 1 (with explicit subscribe)
- Refactors
AwaitCycle()toSubscribe(options)returningiter.Seq2for proper error handling - Introduces
WatchTypeenum to allow subscribing to specific change types (sources/runfiles)
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| runner/pkg/ibp/protocol.go | Introduces ProtocolVersion type, version constants, WatchType enum, and SubscribeMessage structure |
| runner/pkg/ibp/client.go | Refactors client to negotiate protocol versions and implement explicit subscription with error handling via iter.Seq2 |
| runner/runner.go | Updates Watch method to use new Subscribe API with explicit watch type |
| runner/pkg/ibp/BUILD.bazel | Adds dependency on common/logger package |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
c60fbce to
10cc314
Compare
|
66e6ef2 to
a07da35
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
a07da35 to
294db47
Compare
294db47 to
43098e9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| type SubscribeMessage struct { | ||
| Message | ||
| WatchType WatchType `json:"watch_type"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Options:
- single type
- multiple bools (source + runfiles)
- array of types
If a binary says it only wants to subscribe to sources should it be restarted if it's runfiles change? Or we should ignore runfiles? If watching both should should they be distinguished in the CYCLE message somewhere such as a sources[path]: {type: 'runfiles' | 'sources'} flag? :/
|
rules_js support: aspect-build/rules_js#2411 |
|
This will instead be done with a CAP(abilities) request+response instead and sticking with a single subscription per socket connection. |
|
Will be doing the original protocol CAP message instead |



This way binaries such as
aspect_gazelle_runneror formatters can specify they want to receive CYCLE events for any source changes, not only runfiles changes like today.Changes are visible to end-users: no
Test plan