Skip to content

validating default libs are expected (302) before explicitly setting …#545

Open
ravinagill15 wants to merge 1 commit intofeat/pin-send-receive-libfrom
ravina/validate-message-lib-version
Open

validating default libs are expected (302) before explicitly setting …#545
ravinagill15 wants to merge 1 commit intofeat/pin-send-receive-libfrom
ravina/validate-message-lib-version

Conversation

@ravinagill15
Copy link
Copy Markdown
Collaborator

…in config

@changeset-bot
Copy link
Copy Markdown

changeset-bot Bot commented Apr 30, 2026

⚠️ No Changeset found

Latest commit: 57f4ead

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Comment on lines +38 to +47
// `defaultSendLibrary(dstEid)` / `defaultReceiveLibrary(srcEid)` need a peer eid.
// Querying a chain's default for itself isn't a real concept, so pick any other
// chain in scope. (LZ today uses the same lib across all destinations per chain.)
const peer = contracts.find((c) => c.eid !== contract.eid)
if (!peer) {
throw new Error(
`Cannot fetch default message libraries for eid ${contract.eid}: at least one other chain must be in scope.`
)
}

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wondering if we should check defaults for all pathways instead of assuming they're uniform per chain. The Endpoint API stores defaults per destination, so it's technically possible for one chain's default to differ across destinations, and checking only one peer would silently miss that. That is not the case today, but could be in the future

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we run in parallel using Promise.all, the fetches fan out across endpoints and version checks get de-duped to about 64 unique addresses, so performance should be more optimized

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant