Fakes should support workflows with generated bindings#1584
Draft
ernest-nowacki wants to merge 2 commits into
Draft
Fakes should support workflows with generated bindings#1584ernest-nowacki wants to merge 2 commits into
ernest-nowacki wants to merge 2 commits into
Conversation
Contributor
📊 API Diff Results
|
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
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.
Description
cre workflow simulate(cre-cli) writes Solana reports through the mock forwarder fake incontracts/capabilities/fakes. Workflows built with SDK-generated bindings (Gocre-sdk-go, TS@chainlink/cre-sdk) construct reports for production:remainingAccountslayout: index 0 = forwarder state, index 1 = forwarder authority PDA, index 2+ = receiver accounts — taken from workflow config, i.e. the real keystone forwarder;account_hash = sha256(concat(remainingAccount pubkeys)), which the forwarder recomputes on-chain over[state, authority, ...remaining]and rejects on mismatch (Custom:6002 InvalidAccountHash).Since the fake substitutes the mock forwarder's state/authority, the workflow-computed hash never matches and every simulated write fails with
InvalidAccountHash.This PR makes
FakeSolanaChain.WriteReportaccept unmodified production reports:remainingAccounts[0..1](forwarder state + authority), mirroring the real transmitter'sforwarder_client.go, which maps them onto named instruction accounts;account_hashin place over the account list the mock forwarder will actually see:[mock state, mock authority, ...receiver accounts](patchReportAccountHash). Safe because the mock forwarder verifies no DON signatures and the transaction is signed by the fake's transmitter afterwards;infowhenever the hash is rewritten.Net effect: workflows keep their production config — no simulation-specific forwarder addresses, no binding changes,
cre workflow simulateand deploy use identical workflow code.Also adds
contracts/capabilities/fakes/README.mddocumenting the mock-forwarder write path and what receiver authors still need (receiver's own caller validation must accept the mock forwarder).Testing:
TestPatchReportAccountHashcovers hash rewrite, idempotent no-op on second patch, and too-short raw report error. Verified end-to-end viacre workflow simulateon solana-devnet against a bindings-based workflow (sol_cap-canary equivalent).Requires Dependencies
Resolves Dependencies
cre-cliPR that would bumpsgithub.com/smartcontractkit/chainlink-solana/contractsto this commit; once it lands indevelop.