fix(cre): wire ChainWrite.TargetsLimit to non-EVM WriteReport capabilities - #23255
Draft
cawthorne wants to merge 2 commits into
Draft
fix(cre): wire ChainWrite.TargetsLimit to non-EVM WriteReport capabilities#23255cawthorne wants to merge 2 commits into
cawthorne wants to merge 2 commits into
Conversation
…ities
The callLimiters map in capability_executor.go only wired
ChainWriteTargets to {"evm", "WriteReport"}. Aptos, Solana, and
Stellar WriteReport calls were silently unthrottled — the limiter
lookup returned ok=false and the call proceeded unchecked,
regardless of the ChainWrite.TargetsLimit setting.
The settings schema (chainlink-common cresettings.chainWrite) already
defines TargetsLimit as a chain-family-agnostic per-workflow limit,
and the chainWrite struct carries Aptos/Solana sub-structs — the
wiring just never connected them.
Add map entries for aptos, solana, and stellar WriteReport methods,
all pointing to the same limiters.ChainWriteTargets limiter. This
is a 4-line change — the limiter object and settings infrastructure
already exist and are chain-family-agnostic.
Discovered while debugging fire-drill transmit_fault scenarios:
ApplyTransmitFault injects a bad target contract address to cause
write failures, but we investigated whether ChainWrite.TargetsLimit=0
could be used instead (hot-reloadable, no re-register). It cannot,
because Aptos writes bypass the limiter entirely. With this fix,
TargetsLimit=0 would correctly block all chain writes, not just EVM.
Contributor
|
✅ No conflicts with other open PRs targeting |
Contributor
|
I see you updated files related to
|
|
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
2 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.
Summary
ChainWrite.TargetsLimitin CRE settings was silently unthrottled for non-EVM chains. ThecallLimitersmap incapability_executor.goonly wiredChainWriteTargetsto{"evm", "WriteReport"}— Aptos, Solana, and StellarWriteReportcalls bypassed the limiter entirely.The gap
The lookup at
capability_executor.go:101:For an Aptos write,
ParseID("aptos:ChainSelector:4457093679053095497@1.0.0")returnsname="aptos". The map only had{"evm", "WriteReport"}— sook=falseand the call proceeded unchecked.WriteReportexists?callLimiters(before)callLimiters(after)evmaptossolanastellarThe fix
Add 3 map entries — the limiter object (
limiters.ChainWriteTargets) and settings schema (cresettings.chainWrite.TargetsLimit) already exist and are chain-family-agnostic:{"evm", "WriteReport"}: limiters.ChainWriteTargets, {"aptos", "WriteReport"}: limiters.ChainWriteTargets, // new {"solana", "WriteReport"}: limiters.ChainWriteTargets, // new {"stellar", "WriteReport"}: limiters.ChainWriteTargets, // newProduction impact
Any production workflow writing to Aptos/Solana/Stellar has unlimited write targets today, regardless of
ChainWrite.TargetsLimitin the org-level CRE settings. With this fix,TargetsLimit=0correctly blocks all chain writes, not just EVM.How discovered
While debugging fire-drill
transmit_faultscenarios inchainlink-data-feeds. We investigated whetherChainWrite.TargetsLimit=0could replace the bad-contract-address fault (hot-reloadable, no re-register), but found Aptos writes bypassed the limiter — leading to this fix.Test plan
go test ./core/services/workflows/v2/...passes (verified locally)ChainWrite.TargetsLimit = 0on an Aptos-targeted workflow, verify writes are now blocked (previously: writes succeeded)