Skip to content

cre-6798: migrate ConfidentialRelay gateway handler to full DON×shard support - #23988

Draft
bolekk wants to merge 5 commits into
developfrom
cre-6798-confidential-relay-gateway-sharding
Draft

bolekk wants to merge 5 commits into
developfrom
cre-6798-confidential-relay-gateway-sharding

Conversation

@bolekk

@bolekk bolekk commented Oct 14, 2026 •

Copy link
Copy Markdown
Contributor

Summary

  • Migrates the ConfidentialRelay gateway handler off the legacy single-shard DONConfig/DON wiring onto the shared ShardedDONs/ShardEndpoint model (Dummy, WebAPI, and HTTP capability handlers already use it; Vault is in a separate PR, [CRE-6797] Migrate Vault gateway handler to sharded DONs config #23985).
  • handler_factory.go now passes the sharded DON matrix straight through for this handler type instead of flattening to shard 0 of DON 0.
  • Each secrets.get/capability.exec request is routed to exactly one shard, named by workflow_don_name + workflow_don_shard_index in the request params — these requests are not interchangeable across shards, so quorum is no longer raced across all of them. workflow_don_shard_index defaults to 0 when omitted; workflow_don_name may be omitted only when the service has a single DON. Both are fields on chainlink-common's relay params (#2470 merged, #2476 adds the fields). Requires Fix bad geth log decoding #2476 to merge and be released (go.mod currently points at its branch commit).
  • Per-shard quorum math (F+1/2F+1) and rate limiters are otherwise unchanged from the pre-migration single-shard behavior, just parameterized by the resolved shard.

Test plan

  • go test ./core/services/gateway/handlers/confidentialrelay/... -race — all existing tests pass unchanged (single-shard behavior preserved exactly)
  • New tests: fan-out/aggregation stay confined to the selected shard (a response from another shard's node address is ignored), omitted index defaults to shard 0, workflow_don_name selects the DON (required with multiple DONs, unknown rejected), out-of-range shard_index is rejected
  • go build ./core/services/gateway/... and golangci-lint run clean

Deployment Validation

Existing canaries; confidential-relay quorum/success metrics continue reporting non-zero.

🤖 Generated with Claude Code

… support

Replace the legacy single-shard DONConfig/DON wiring with the shared
ShardedDONs/ShardEndpoint model (as Dummy/WebAPI/HTTP already use).
Quorum (F+1/2F+1) and rate limiters are now evaluated per shard
independently; the first shard to reach quorum wins, and a shard whose
quorum becomes unreachable no longer fails the whole request on its own.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown
Contributor

I see you updated files related to core. Please run make gocs in the root directory to add a changeset as well as in the text include at least one of the following tags:

  • #added For any new functionality added.
  • #breaking_change For any functionality that requires manual action for the node to boot.
  • #bugfix For bug fixes.
  • #changed For any change to the existing functionality.
  • #db_update For any feature that introduces updates to database schema.
  • #deprecation_notice For any upcoming deprecation functionality.
  • #internal For changesets that need to be excluded from the final changelog.
  • #nops For any feature that is NOP facing and needs to be in the official Release Notes for the release.
  • #removed For any functionality/config that is removed.
  • #updated For any functionality that is updated.
  • #wip For any change that is not ready yet and external communication about it should be held off till it is feature complete.

@github-actions

Copy link
Copy Markdown
Contributor

✅ No conflicts with other open PRs targeting develop

@trunk-io

trunk-io Bot commented Oct 14, 2026 •

Copy link
Copy Markdown

Static Badge   Static Badge   Static Badge

View Full Report ↗︎ ⋅ Docs

Fan-out previously raced every configured shard and forwarded whichever
reached quorum first, which is wrong here: secrets.get/capability.exec
requests are not interchangeable across shards. The enclave now selects
the shard via an explicit shard_index in request params (bumped to
chainlink-common's new *int ShardIndex field, PR
smartcontractkit/chainlink-common#2470); a missing value is rejected
rather than defaulted to shard 0, since 0 is itself a valid shard.

fanOutToNodes, evaluateShard (renamed from evaluateShards), and
forwardAfterGrace now operate on the single resolved shard instead of
looping over all of them.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@cl-sonarqube-production

Copy link
Copy Markdown

bolekk and others added 3 commits October 14, 2026 22:33
Match chainlink-common#2470's simplified design (ShardIndex went from
*int to plain int): a request without shard_index now routes to shard
0 instead of being rejected.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A gateway service can attach several DONs, so shard_index alone was
ambiguous. The handler now picks the DON named by don_name (optional
when there is a single DON) and the shard_index within it. Bumps
chainlink-common to the branch adding DonName (#2476).

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…on_shard_index

Follows the field rename in chainlink-common#2476.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
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.

1 participant