Repository navigation
Conversation
added 4 commits
September 29, 2026 14:43
… of a chain
SubscribeChainStatus streams one merged view per chain: the union of methods,
the minimum of lower bounds and the maximum head over all upstreams. That view
advertises combinations no single node has, so a consumer routing by it sends
requests no node can serve. SubscribeUpstreamStatus streams the inputs of that
merge instead, one entry per upstream, and leaves the grouping to the consumer.
- SubscribeUpstreamStatusRequest{chains}: the chains to stream, empty = all.
- SubscribeUpstreamStatusResponse{chain, upstreams, full_response, build_info}:
every response lists all upstreams of the chain, so an upstream missing from
it is gone. Full responses (the first of a chain and one every resync)
describe every upstream and carry build_info.
- UpstreamStatus{upstream_id, status, head, description}: description holds
the ChainEvents SubscribeChainStatus sends for a chain (methods,
subscriptions, lower bounds, finalization, labels as one NodeDetails), for
this upstream alone; it is present when it changed and on full responses.
upstream_id is the id NativeCallReplyItem.upstream_id already reports. A
request is pinned to upstreams with a forwarded label selector named
upstream_id, so no new selector and no new reply field are needed.
Additive: SubscribeChainStatus and every existing message are unchanged, and a
server without the RPC answers Unimplemented.
…treams A delta used to list every upstream of the chain, so a head moving on one node re-sent the heads of all of them. Deltas now carry only the upstreams that are new or changed plus removed_upstream_ids; full responses (the first of a chain and one every resync) still list and describe every upstream, so a consumer that missed nothing stays exact and a resync repairs one that did.
…comments node_level_error marks an error the serving upstream (or the pin) caused rather than the request, so a client that pinned the request to upstreams knows another upstream may answer it without matching error texts. The UpstreamStatus comments now say what a listed upstream always carries and when description is present.
l0gun0v
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem and resulting behavior
Merged chain capabilities can advertise combinations that no node supports. Add a separate API for nodecore-owned groups so discovery and execution use the same membership definition, while retaining the existing chain-status contract.
Changes and flow
SubscribeNodeGroupStatus, with optional chain filters andfull_separationfor one upstream per group.compact_updates: unchanged descriptions and member indices can be omitted in head-only deltas. Clients retain that metadata. Initial snapshots, metadata changes and resync remain complete; the default remains full descriptions.node_group_idlabel selector at the top level or under AND. Nodecore resolves current membership; consumers never reconstruct IDs or send their own membership snapshot. Empty/multiple IDs and group expressions under OR/NOT fail closed.NativeCallReplyItem.node_level_errorso consumers can retry node-specific failures through their existing request policy.The resulting flow is nodecore group catalog → aggregator format adapter → ordinary dproxy group provider →
node_group_idselector → nodecore's current members. A later attempt may choose another eligible group of the same provider.Validation and rollout
go test ./...passed. Matching consumers passed race-instrumented network tests for full/delta/resync, group lifecycle, routing, retries, stale group rejection, sticky filters and subscriptions. The harness uses controlled blockchain nodes; public ingress, authentication and billing deployment are outside it.Merge this API before nodecore #392 and dproxy #2994. Both consumers pin the published API revision and are checked without a local Go workspace.
The API exposes group discovery and the existing chain stream; the intermediate per-upstream discovery endpoint and its generated types have been removed.
Main integration
Merged main at
a2445cc, including the Celestia API/method additions. Public tests passed; consumers pin this merged revision.