Repository navigation
[pull] develop from smartcontractkit:develop - #640
Merged
Merged
Conversation
…config (#23830) * Migrate Dummy and WebAPI (v0.1) gateway handlers to sharded DONs Both handlers previously only worked against a single DON shard, because handler_factory.go collapsed the full shardedDONs/shardsConnMgrs matrix down to shard 0 of DON 0 before constructing them. Add a shared handlers.NodeRouter that expands a DON×shard matrix into a node address -> connection manager lookup, and use it in: - DummyHandler: fan out requests to every node across every DON/shard. - WebAPI (v0.1 web-api-capabilities) handler: route the HTTP fetch response back through the connection manager that actually owns the requesting node, instead of a single fixed one. handler_factory.go now passes shardedDONs/shardsConnMgrs straight through for these two handler types, matching the HTTP capability handler. Vault and ConfidentialRelay still use the legacy single-shard conversion; see z_tracker/projects/gateway_handler_sharding.md for the follow-up plan (CRE-1640). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Bundle shardedDONs/shardsConnMgrs into a ShardedDONs struct DummyHandler and the WebAPI (v0.1) handler threaded shardedDONs and shardsConnMgrs as two parallel slices that must always agree in length, re-validating that invariant independently in handler_factory.go and BuildNodeRouter. Introduce handlers.ShardedDONs to pair them once, via NewShardedDONs, and give it a BuildNodeRouter method so handler constructors take a single validated value instead of two slices. node_router.go is renamed to shard_endpoints.go to hold it, mirroring the naming already used for the analogous matrix-builder in capabilities/v2. Have the HTTP capability handler take *handlers.ShardedDONs too NewGatewayHandler (v1.0 HTTP capabilities) still took shardedDONs and shardsConnMgrs as two parallel slices, so its own buildShardEndpoints re-validated the same length/nil invariants that ShardedDONs already checks. Switch it to accept *handlers.ShardedDONs like DummyHandler and the WebAPI (v0.1) handler now do, and drop the now-redundant validation from buildShardEndpoints, which only needs to check that shard memberships are disjoint. Unify NodeRouter and v2's shardEndpoint into one ShardEndpoint type We had two structs doing the same DON×shard matrix expansion: handlers.NodeRouter (a flat nodeAddr -> connMgr map, used by DummyHandler and the WebAPI v0.1 handler) and v2's private shardEndpoint (which also kept the shard's donID/F, used by the HTTP v1.0 capability handler and its trigger/metadata sub-handlers). Replace both with a single exported handlers.ShardEndpoint plus a (*ShardedDONs).BuildShardEndpoints method in handlers/shard_endpoints.go, and point every handler (Dummy, WebAPI v0.1, HTTP v1.0) at it. Delete v2/shard_endpoints.go now that its logic lives in one place. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
…ng (#23850) * llo/datasource: fix flaky atomic cache write test * llo: fix integration tests for aggregation fault tolerance * llo: v31 aggregation fault tolerance integration tests * llo: blob catch-up integration tests * llo/bench: v31 blob broadcast and fetch failure paths tests * llo: observation compression tests with every report format * llo: v31 oracle restart tests * llo: assert attested retirement report at handover tests * llo: drop stale test stubs * llo: rename OCR31 selector to V31 Align the delegate config, test helpers and job plugin config key with the plugin version naming: OCR31 -> V31, IsOCR31 -> IsV31, WithOCR31 -> WithV31, and the TOML key ocrVersion = "3.1" -> pluginVersion = "v31". * bump chainlink-data-streams * llo: wire v31 plugin config knobs through The v31 knobs parsed and validated in pluginconfig.V31Config never reached the plugin factory, so every job ran on the plugin defaults.
* Support refreshing CombinedClient info and idempotent shim Close() CombinedClient's embedded CapabilityInfo (including DON metadata) was frozen at construction with no way to update it, so DON member/family changes never propagated once a CombinedClient was cached. Add SetInfo to refresh it in place. triggerSubscriber/triggerPublisher.Close() closed a channel directly with no guard, panicking on a second call. Guard with sync.Once so future callers (e.g. pruning stale shims) can safely close a shim that might already be closed elsewhere. Prune stale remote capability shims in the launcher addRemoteCapabilityV2/serveCapabilityV2 only ever created or updated cachedShims entries - nothing ever removed one. When a capability, method, or DON dropped out of the registry (or a capability moved to a different DON ID), its trigger subscriber/publisher, executable client/server, and CombinedClient shims lingered forever: still registered with the dispatcher and, for CombinedClients, still occupying their capability ID in the local capabilities registry. Add computeWantedShimKeys, a dry-run pass over the same DON/capability config that mirrors addRemoteCapabilities/serveCapabilities' filtering without creating anything, and pruneStaleShims, which tears down any cached shim not in that wanted set: deregister from the dispatcher, Close() the shim, drop it from subServices, and (for CombinedClients) remove it from the capabilities registry. Pruning must run before the create/update loops, not after: a capability moving to a new DON ID needs its old CombinedClient removed from the registry first, since CombinedClient doesn't implement GetState() (registry.Add treats it as an unknown/unsafe-to-replace connectivity state and errors with ErrCapabilityAlreadyExists otherwise) and each DON ID gets a distinct CombinedClient object. Also switch shimKey from a formatted string to a small comparable struct, so pruning doesn't need to parse it back into capID/donID/ method. Add tests for shim pruning and capability DON reassignment Covers: a remote capability removed entirely from a DON's config (client-side shims and CombinedClient pruned, dispatcher deregistered); a served capability's method removed from a DON's config (server-side shims pruned); a capability moving to a different DON ID (old CombinedClient removed from the registry before the new one is added, without ErrCapabilityAlreadyExists); and CombinedClient.Info() reflecting updated DON metadata when the DON ID itself is unchanged. * Address review feedback: rename shimKey to shimID, use slices.Delete - Rename shimKey -> shimID per review: "key" was redundant since it's used as a general shim identifier, not just a map key. - Use slices.Delete instead of manual append-based slice removal in closeStaleShim. - Document that triggerSubscriber/triggerPublisher.Close() are safe to call more than once, with only the first call able to return an error; addresses review question about double-close swallowing the error. - Add changeset. SHARED-1014
* feat: add CoordinatedEngine featureflag * chore: clean up unused OnSubscriptionsReady * feat: define TriggerCoordinator interface * feat: wire the noop trigger coordinator * feat: add metrics to count type of engines * test: cleanup unused OnSubscriptionsReady * chore: refactor tryEngineCreate to have clear separate path for legacy and coordinated engine * fix: lint issues * chore: log errors, improve logs, explicit return on err * chore: bump chainlink-common and use cresettings.Default.CoordinatedEngineEnabled * fix: check engine is coordinated, as triggerCoordinator is always wired * fix: remove coordinated from the engine registry, type assert this from the engine itself * refactor: use one factory for legacy and coordinated engines * chore: build cleanup func to dedup * fix: lint issues * chore: newEngine calls useCoordinatedEngine instead of forcing the factoryfn to receive the parameter * test: add tests covering sharding + alternative scenarios for coordinated engine * chore: return ErrCoordinatedShardingUnsupported on sharding coordinated engine methods
* Bumped cl-evm * Fixed docs tests * Added changeset
RegisterTrigger runs asynchronously; waitForRegistration only confirms the call reached the underlying mock, not that the publisher has recorded the registration in its internal map. If the unregister message won that race, the handler saw the trigger as unregistered and dropped it, causing the test to time out waiting on waitForUnregister. Wait for a registration check (only sent for triggers already in the registration map) before issuing the unregister, closing the window. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
* Switch test workflow to use http instead of cron * Cache compiled workflows * Fixed go mod * Revert timeout back to 7 minutes * Cleaned up comments
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
6 participants
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )