basic stellar support in ccv#626
Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates dependencies and extends the dev environment EVM implementation to recognize Stellar as a supported chain family for CCV-related configuration and message extra-args serialization.
Changes:
- Bump
github.com/smartcontractkit/chain-selectorstov1.0.97(and propagate sum updates across modules). - Update several indirect AWS SDK v2 dependencies and
github.com/go-errors/errors. - Add Stellar handling in dev environment logic (extra-args serialization and address length selection) and populate Stellar signer info in topology enrichment.
Reviewed changes
Copilot reviewed 4 out of 7 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
indexer/cmd/oapigen/go.sum |
Updates chain-selectors sums for the oapigen module. |
go.sum |
Reflects updated dependency graph (AWS SDK v2 components, go-errors/errors, chain-selectors). |
go.mod |
Bumps chain-selectors; updates indirect AWS SDK v2 deps; adds indirect go-errors/errors v1.5.1. |
build/devenv/fakes/go.sum |
Updates chain-selectors sums for devenv fakes module. |
build/devenv/fakes/go.mod |
Bumps indirect chain-selectors to v1.0.97. |
build/devenv/evm/impl.go |
Adds Stellar as a destination family for extra-args serialization and uses 32-byte address length for Stellar in selector wiring. |
build/devenv/environment.go |
Adds Stellar signer address enrichment using bootstrap EdDSA public key. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| panic(fmt.Sprintf("unsupported message extra args version: %d", opts.Version)) | ||
| } | ||
| case chainsel.FamilyStellar: | ||
| return serializeExtraArgsV3(opts) |
There was a problem hiding this comment.
For FamilyStellar, serializeExtraArgs always returns V3 encoding regardless of opts.Version. This silently ignores caller intent and can produce mismatched extra-args for Stellar without any error (unlike the EVM/Canton and Solana branches which validate supported versions). Consider explicitly validating opts.Version (e.g., only allow 3) and panic/error with a family-qualified message when an unsupported version is provided.
| return serializeExtraArgsV3(opts) | |
| switch opts.Version { | |
| case 3: // StellarExtraArgsV3 (uses EVMExtraArgsV3 encoding) | |
| return serializeExtraArgsV3(opts) | |
| default: | |
| panic(fmt.Sprintf("unsupported message extra args version for family %s: %d", destFamily, opts.Version)) | |
| } |
| panic(fmt.Sprintf("unsupported message extra args version: %d", opts.Version)) | ||
| } | ||
| case chainsel.FamilyStellar: | ||
| return serializeExtraArgsV3(opts) |
There was a problem hiding this comment.
New Stellar-specific behavior was added (extra-args serialization), but there don’t appear to be any tests exercising Stellar destinations (no Stellar references under build/devenv/tests). Adding at least a small unit/integration test that asserts Stellar uses the expected extra-args version/encoding would help prevent regressions as more families/versions are added.
| return serializeExtraArgsV3(opts) | |
| switch opts.Version { | |
| case 3: // Stellar currently uses EVMExtraArgsV3 encoding | |
| return serializeExtraArgsV3(opts) | |
| default: | |
| panic(fmt.Sprintf("unsupported message extra args version for family %s: %d", destFamily, opts.Version)) | |
| } |
|
Code coverage report:
|
No description provided.