DF-25025: Remove forwarder EOA fallback#22836
Open
cl-efornaciari wants to merge 2 commits into
Open
Conversation
When forwarding is enabled and the forwarder address cannot be resolved (e.g. RPC unavailable at node boot), GetEVMEffectiveTransmitterID previously logged a warning and silently fell back to the EOA. That EOA was then baked into the effective transmitter, permanently disabling forwarding for the process lifetime so the job could not transmit and did not recover without a restart. Return the error instead so a forwarding job either uses its forwarder or fails honestly (recorded and retried on the next boot once RPC is warm). DF-25025
product-security-plaid-production
Bot
requested review from
MStreet3 and
jmank88
Contributor
|
👋 cl-efornaciari, thanks for creating this pull request! To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team. Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks! |
cl-efornaciari
changed the title
Contributor
|
✅ No conflicts with other open PRs targeting |
Contributor
|
I see you updated files related to
|
jmank88
approved these changes
Jun 12, 2026
|
|
|
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.
Motivation
When forwarding is enabled, the node determines the OCR transmitter by resolving the forwarder contract for the configured EOA via an RPC call at job startup. If that RPC call fails — most commonly because the EVM
MultiNodehas not selected a live RPC yet during node boot (no live nodes available) — the previous code logged a warning and silently fell back to the EOA.That fallback is sticky and harmful:
ocr2FeedsTransmitter), the tx-time forwarder lookup is gated onslices.Contains(fromAddresses, effectiveTransmitterAddress), so once the EOA is the effective address, forwarding is permanently disabled.This is the DF-25025 reliability issue: an RPC blip at boot leaves forwarding jobs running on the wrong transmitter until they are manually restarted.
Change
Remove the forwarder→EOA fallback so a forwarding-enabled job either uses its forwarder or fails honestly. On forwarder-resolution failure the service now returns the error, which the job spawner records (
TryRecordError) and re-attempts on the next boot — when the RPC is warm and the correct forwarder can be resolved.core/services/ocr2/delegate.go(GetEVMEffectiveTransmitterID): return theGetForwarderForEOAerror instead ofWarnw+ returning the EOA.core/services/ocr/delegate.go(ServicesForSpec): same treatment for the OCR1 forwarding path.Behavior change / risk
Forwarding-enabled jobs will now fail to start when the forwarder cannot be resolved at boot (e.g. cold RPC), where they previously started on the EOA. This is intended: an explicit, recorded failure that self-heals on the next boot is preferable to a silent, unrecoverable misconfiguration. This matches the existing "recovers on restart" behavior operators already rely on.
Scope is limited to the boot-time transmitter determination. The tx-time EOA fallbacks in the Median transmitter and broader boot-time RPC resilience (e.g. spawner retry, log-poller
RegisterFilter/CodeAttolerance) are intentionally out of scope.Testing
go build ./core/services/ocr2/ ./core/services/ocr/go test ./core/services/ocr2/(incl.TestGetEVMEffectiveTransmitterID, updated to assert an error rather than the EOA fallback)go test ./core/services/ocr/