fix: normalize OCR3 transmitter encoding in LocalRegistry

[cawthorne]

Summary

• normalize OCR3 transmitter accounts to hex text when LocalRegistry unmarshals CapReg OCR3 configs
• add regression coverage for the LocalRegistry OCR3 config path

Why

Aptos capability startup can fall back to ConfigForCapability(...) when p2pToTransmitterMap is not present in the worker JSON config. In staging, that call goes through the external registry syncer into LocalRegistry, then back across the loop bridge through chainlink-common.

Note: registrysyncer.LocalRegistry is not just a local-CRE test path; it is also the synced local copy of the external onchain Capabilities Registry used in staging and other non-local environments.

chainlink-common expects OCR transmitter accounts to be hex-encoded text on that loop boundary, but LocalRegistry.Unmarshal() was reconstructing them as raw bytes inside ocrtypes.Account. That leaves the producer and consumer with different expectations and causes the same decode failure we previously worked around in chainlink-common.

This fixes the producer-side contract instead of adding another tolerant fallback in the loop bridge.

Testing

• GOWORK=off go test ./core/services/registrysyncer -run 'TestCapabilityConfiguration_Unmarshal' -count=1
• GOWORK=off go test ./core/services/cre -run TestNonExistent -count=1

[github-actions]

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]

✅ No conflicts with other open PRs targeting develop

[trunk-io]

     

View Full Report ↗︎ ⋅ Docs

[Copilot]

Pull request overview

Risk Rating: HIGH (changes cross-component serialization semantics for OCR3 transmitters, which can affect runtime interoperability)

Normalizes OCR3 transmitter account encoding during LocalRegistry capability config unmarshalling so the registry-sync path produces the same hex-text representation expected across the loop boundary (not raw bytes).

Changes:

• Hex-encode OCR3 Transmitters on CapabilityConfiguration.Unmarshal() via hex.EncodeToString.
• Update existing OCR3 config unmarshal test expectations to match hex-text normalization.
• Add a regression test to ensure transmitter bytes (including ASCII bytes) are normalized to hex text.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
core/services/registrysyncer/local_registry.go	Hex-encodes OCR3 transmitters during unmarshal to align producer-side serialization with loop-boundary expectations.
core/services/registrysyncer/local_registry_test.go	Updates OCR3 transmitter assertions and adds regression coverage for transmitter normalization behavior.

Areas needing scrupulous human review:

• core/services/registrysyncer/local_registry.go OCR3 transmitter normalization loop (around the hex.EncodeToString change): confirm downstream consumers expect no 0x prefix and lowercase hex across all relevant chains/capabilities.

[cl-sonarqube-production]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube