Expose message retrieval by ID (API) as a CCIPAPIClient method #97
Conversation
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
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| return raw.map((ta) => ({ | ||
| token: ta.tokenAddress, | ||
| amount: BigInt(ta.amount), | ||
| // TODO: API does not provide pool addresses - these require on-chain lookup |
There was a problem hiding this comment.
Let's discuss what's the best approach here.
| ) | ||
| } | ||
|
|
||
| const url = `${this.baseUrl}/v1/messages/${encodeURIComponent(messageId)}` |
There was a problem hiding this comment.
Let's keep in mind the order of dependencies between the different components and their rollout plans before merging this.
Contributor
Author
There was a problem hiding this comment.
Retargeted the PR base to feat/APIv2 (A staging branch for the purpose of behaviour that only works with the new schema)
Coverage Report |
PabloMansanet
force-pushed
the
retrieve_from_api_by_ID
branch
from
e56402a to
4ccdb3e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
Targeted at a staging branch so we don't merge to
mainchanges that work only for the unreleased API. Unit tested and tested manually through a localhost deployment of the latest CCIP API:What this is
This PR introduces a method to the CCIP API Client that requests a message by messageId, agnostic about any other environment data (CCIP message IDs are unique so this will work across chains and onramps).
To verify the behaviour, I also added a CLI command in the same style as the one for
getLatency. The fields exposed by it are a smaller subset but can be expanded to be more informative if needed.Return type concerns
Currently, the return type of the method is a composite of a
Partialform ofCCIPRequest, and aMetadatatype. The reasons for this are:CCIPRequestis available from the API alone.CCIPRequest.This works fine for now (and could be merged as-is if needed) but ideally we iterate on this until we find a clean common type that we can reuse directly, with the tradeoff of having some optional fields. Reaching this will likely require tweaks on both sides. Here are the rough edges that I found, and how I think we should tackle them:
MessageStatusenum (SDK side) does not yet support 1.7 statuses, where the one in the API does. This is fine and shouldn't be a blocker, because the enums are completely compatible otherwise. Before the SDK supports 1.7, an attempt to retrieve a 1.7 message will fail on validation, which is the expected behaviour.TokenAmountsin the API currently only include the token address on source + the transferred amount, where the SDK expects detailed info including source pool address, destination pool address, extraData and destGasAmount. We could expose this in the API, but I wanted to check with @andrevmatos whether there's a usecase for these fields or whether we can KISS for now. EDIT: Opened a jira ticket to handle the API change needed to expose this data.APICCIPRequestMetadata) which are retrieved from the API and don't exist directly in theCCIPRequesttype. I have no strong opinion on whether these should be integrated intoCCIPRequestor should remain on the side.CCIPRequesttype fields and the API responses. For example, thenonceoronrampmay not exist in the API response whereCCIPRequestexpects it. In case of absence, I've defaulted them to empty values for this draft, but it would be good to make informed decisions on why they're optional or not in either side, unify the ones that can be unified, and converge on what to do otherwise.