feat(gateway-v4): expose output tokens #781
Conversation
|
Warning Rate limit exceeded@mastilver has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 11 minutes and 46 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (4)
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughThe gateway client now computes per-order outputTokenAddress/outputTokenAmount (preferring tokensReceived with legacy fallbacks), resolves token metadata from that computed address, and exposes per-order fields and helpers: outputTokenAddress, outputTokenAmount, getTokenAmount (function), getTokens, and getOutputTokens. Types and tests updated accordingly. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant U as Caller
participant C as GatewayClient
participant G as Gateway API
participant L as TokenLookup
U->>C: getOnrampOrders()
C->>G: fetch onramp orders
G-->>C: OnrampOrderResponse[]
rect rgba(200,230,255,0.35)
note right of C: Enrich each order
C->>C: compute outputTokenAddress/outputTokenAmount\n(prefer tokensReceived, else legacy fields)
C->>L: resolve token metadata by computed address
L-->>C: Token metadata
C->>C: attach helpers: getTokenAmount (fn), getTokens, getOutputTokens
end
C-->>U: OnrampOrder[] (enriched)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
mastilver
force-pushed
the
feat/gateway-v4-expose-output-tokens
branch
from
a85dbd6 to
35da737
Compare
Summary of ChangesHello @mastilver, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly upgrades the Gateway V4 SDK by implementing robust support for handling and exposing multiple output tokens for on-ramp orders. It refactors the core client logic to prioritize a new Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces the ability to expose output tokens for gateway v4 orders. It adds new properties to the OnrampOrderResponse type and modifies the GatewayApiClient to handle these new properties. The changes include adding outputTokenAddress and outputTokenAmount to the OnrampOrder type, creating getOutputTokens and getTokens methods, and updating the getOnrampOrders method to use these new methods. Additionally, a new test case is added to verify the functionality of retrieving multiple output tokens.
sdk/src/gateway/client.ts
Outdated
| const outputTokenAddress = | ||
| order.outputTokenAddress ?? order.tokensReceived?.[0]?.token_address ?? undefined; |
There was a problem hiding this comment.
Consider extracting this logic into a separate helper function to improve readability and maintainability. This will also reduce code duplication.
Also, the ?? undefined is redundant, as the nullish coalescing operator already returns undefined if the left-hand side is null or undefined.
| const outputTokenAddress = | |
| order.outputTokenAddress ?? order.tokensReceived?.[0]?.token_address ?? undefined; | |
| const outputTokenAddress = order.outputTokenAddress ?? order.tokensReceived?.[0]?.token_address; | |
| const outputTokenAmount = order.outputTokenAmount ?? order.tokensReceived?.[0]?.amount; |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
sdk/src/gateway/client.ts (1)
1096-1101: Consider tokensReceived when computing success statusFor v4, outputTokenAddress can be null while tokensReceived is present. Use the computed outputTokenAddress (with v4 fallback).
Apply this diff:
- ? order.strategyAddress - ? order.outputTokenAddress + ? order.strategyAddress + ? outputTokenAddress ? { success: true, data } : { success: false, data } : { success: true, data }
🧹 Nitpick comments (5)
sdk/src/gateway/types.ts (1)
330-332: Fix typos and consider making tokensReceived optional
- Typo: “gatway” → “gateway”.
- The client defensively accesses this via optional chaining. If the API can omit the field, make it optional to reflect reality.
Apply this diff to fix the doc typo and (optionally) make the field optional:
- /** tokens received for gatway v4 order */ - tokensReceived: TokenReceived[] | null; + /** @description Tokens received for gateway v4 order */ + tokensReceived?: TokenReceived[] | null;Please confirm whether the Gateway API always includes tokensReceived (possibly null) or can omit it. If it’s always present, keep it required and just fix the docstring.
sdk/test/gateway.test.ts (1)
437-531: Great coverage for v3/v4 output token flows
- Validates pending, v3 single-output, and v4 tokensReceived flows across getTokenAmount/getTokenAddress/getToken and new helpers.
- Nice use of TBTC constants for clarity.
Optionally, add an assertion for getStatus on the v4 case (status: true + tokensReceived present) to prevent regressions once client logic checks tokensReceived for success.
sdk/src/gateway/client.ts (3)
1025-1027: Broaden return type of getTokenAddress to avoid unsoundnessAt runtime this can be undefined (e.g., pending + strategy with no output yet). Match the public type.
Apply this diff:
- const getTokenAddress = (): string => { + const getTokenAddress = (): string | undefined => { return getFinal(order.baseTokenAddress, outputTokenAddress); };
1028-1037: Guard against negative decimal exponent in amount conversionIf a token has fewer than 8 decimals, Math.pow(10, token.decimals - 8) becomes fractional, which is likely unintended.
Apply this diff:
const getTokenAmount = () => { let amount = order.satoshis - order.fee; const token = getToken(); - if (token && !outputTokenAmount) { - amount *= Math.pow(10, token.decimals - 8); - } + if (token && !outputTokenAmount && token.decimals >= 8) { + amount *= Math.pow(10, token.decimals - 8); + } return getFinal(amount, outputTokenAmount); };
1081-1083: Populate outputToken using the computed outputTokenAddressThis ensures v4 tokensReceived-derived outputs are surfaced.
Apply this diff:
- outputToken: ADDRESS_LOOKUP[chainId][order.outputTokenAddress!], + outputToken: outputTokenAddress ? ADDRESS_LOOKUP[chainId][outputTokenAddress] : undefined,
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
sdk/src/gateway/client.ts(4 hunks)sdk/src/gateway/types.ts(4 hunks)sdk/test/gateway.test.ts(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (2)
sdk/test/gateway.test.ts (1)
sdk/src/gateway/client.ts (1)
MAINNET_GATEWAY_BASE_URL(67-67)
sdk/src/gateway/client.ts (1)
sdk/src/gateway/tokens.ts (2)
ADDRESS_LOOKUP(377-377)getTokenAddress(441-449)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: test
🔇 Additional comments (4)
sdk/src/gateway/types.ts (3)
289-293: LGTM on new TokenReceived typeShape matches the API payload and supports v4 multi-output.
321-324: Nullable outputToken fields are appropriateAllowing null aligns with pre-/post-swap states. No further changes needed here.
359-386: Doc typos + sync vs async mismatch with client implementation
- JSDoc: “@dcription” → “@description” (Lines 382 and 385).
- Interface methods here return Promise, but the client currently implements them synchronously. Either:
- Make client methods async (preferred), or
- Change these method types to be synchronous.
Apply this diff to fix the doc typos:
- /** @dcription Get all the output tokens */ + /** @description Get all the output tokens */ getOutputTokens(): Promise<{ amount: string; token: Token }[]>; - /** @dcription Get all the tokens */ + /** @description Get all the tokens */ getTokens(): Promise<{ amount: string | number; token: Token }[]>;Note: See my client.ts comments for making the methods async to match these signatures.
sdk/src/gateway/client.ts (1)
1010-1013: Remove redundant “?? undefined”The trailing “?? undefined” is unnecessary with nullish coalescing.
Apply this diff:
- const outputTokenAddress = - order.outputTokenAddress ?? order.tokensReceived?.[0]?.token_address ?? undefined; - const outputTokenAmount = order.outputTokenAmount ?? order.tokensReceived?.[0]?.amount ?? undefined; + const outputTokenAddress = order.outputTokenAddress ?? order.tokensReceived?.[0]?.token_address; + const outputTokenAmount = order.outputTokenAmount ?? order.tokensReceived?.[0]?.amount;
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
sdk/src/gateway/client.ts (1)
1010-1012: Redundant nullish coalescing with undefined.The
?? undefinedis redundant since the nullish coalescing operator already returnsundefinedwhen the left operand is nullish.- const outputTokenAddress = - order.outputTokenAddress ?? order.tokensReceived?.[0]?.token_address ?? undefined; - const outputTokenAmount = order.outputTokenAmount ?? order.tokensReceived?.[0]?.amount ?? undefined; + const outputTokenAddress = order.outputTokenAddress ?? order.tokensReceived?.[0]?.token_address; + const outputTokenAmount = order.outputTokenAmount ?? order.tokensReceived?.[0]?.amount;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
sdk/src/gateway/client.ts(3 hunks)sdk/test/gateway.test.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- sdk/test/gateway.test.ts
🧰 Additional context used
🧬 Code graph analysis (1)
sdk/src/gateway/client.ts (1)
sdk/src/gateway/tokens.ts (2)
ADDRESS_LOOKUP(377-377)getTokenAddress(441-449)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: test
🔇 Additional comments (6)
sdk/src/gateway/client.ts (6)
1025-1027: LGTM!The token address resolution correctly uses the computed
outputTokenAddressinstead of accessingorder.outputTokenAddressdirectly, ensuring consistency with thetokensReceiveddata.
1028-1037: LGTM!The
getTokenAmountfunction properly handles token amount calculation with decimal conversion and uses the computedoutputTokenAmountfor consistency.
1053-1065: Make getOutputTokens async to match expected signature.The function should be async to align with the type signature, as indicated in the past review comments.
Apply this diff:
- const getOutputTokens = () => { + const getOutputTokens = async () => { const tokens = order.tokensReceived ? order.tokensReceived : outputTokenAmount && outputTokenAddress ? [{ amount: outputTokenAmount, token_address: outputTokenAddress }] : []; - return tokens.map(({ amount, token_address }) => ({ - amount: amount, - token: ADDRESS_LOOKUP[chainId][token_address], - })); + return tokens.map(({ amount, token_address }) => ({ + amount, + token: ADDRESS_LOOKUP[chainId][token_address], + })); };
1066-1076: Make getTokens async and handle missing token data gracefully.The function should be async and return an empty array when no concrete token data is available, as suggested in past reviews.
Apply this diff:
- const getTokens = () => { - const tokens = order.tokensReceived - ? order.tokensReceived - : [{ amount: getTokenAmount(), token_address: getTokenAddress() }]; - - return tokens.map(({ amount, token_address }) => ({ - amount: amount, - token: ADDRESS_LOOKUP[chainId][token_address], - })); - }; + const getTokens = async () => { + if (order.tokensReceived) { + return order.tokensReceived.map(({ amount, token_address }) => ({ + amount, + token: ADDRESS_LOOKUP[chainId][token_address], + })); + } + const addr = getTokenAddress(); + const amt = getTokenAmount(); + if (!addr || amt === undefined) { + return []; + } + return [ + { + amount: amt, + token: ADDRESS_LOOKUP[chainId][addr], + }, + ]; + };
1079-1081: LGTM!The new properties
outputTokenAddressandoutputTokenAmountare properly exposed on the returned order object, providing direct access to computed token information.
1087-1090: LGTM!The helper methods
Based on the web search results, I can now provide additional context for the review comments regarding async function signatures in TypeScript.getTokenAmount,getTokens, andgetOutputTokensare correctly exposed as function properties on the order object, providing a clean API for token data access.
| const getOutputTokens = () => { | ||
| const tokens = order.tokensReceived | ||
| ? order.tokensReceived | ||
| : outputTokenAmount && outputTokenAddress | ||
| ? [{ amount: outputTokenAmount, token_address: outputTokenAddress }] | ||
| : []; | ||
|
|
||
| return tokens.map(({ amount, token_address }) => ({ | ||
| amount: amount, | ||
| token: ADDRESS_LOOKUP[chainId][token_address], | ||
| })); | ||
| }; | ||
|
|
||
| const getTokens = () => { | ||
| const tokens = order.tokensReceived | ||
| ? order.tokensReceived | ||
| : [{ amount: getTokenAmount(), token_address: getTokenAddress() }]; | ||
|
|
||
| return tokens.map(({ amount, token_address }) => ({ | ||
| amount: amount, | ||
| token: ADDRESS_LOOKUP[chainId][token_address], | ||
| })); | ||
| }; | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
Confirm async requirement for getOutputTokens and getTokens functions.
According to TypeScript documentation, async functions always return a promise and a function marked with async will return a Promise. The past review comments correctly identified that these functions should be async to match their expected Promise return types.
🏁 Script executed:
#!/bin/bash
# Description: Check if there are type definitions that expect these functions to return Promises
# Search for type definitions or interfaces that reference these function names
rg -nP --type=ts -C3 'getOutputTokens.*Promise|getTokens.*Promise'
# Search for the OnrampOrder type definition to confirm expected return types
ast-grep --pattern 'interface OnrampOrder {
$$$
getOutputTokens: $$$
$$$
}'
# Also check for type definitions in general
ast-grep --pattern 'type $_ = {
$$$
getOutputTokens: $$$
$$$
}'Length of output: 1460
Make getOutputTokens and getTokens return Promises (mark as async or wrap returns with Promise.resolve)
types.ts declares getOutputTokens(): Promise<...> and getTokens(): Promise<...>, but in sdk/src/gateway/client.ts (lines ~1053–1076) those are synchronous arrow functions returning arrays — update them to async (or return Promise.resolve([...])) so the implementations match the declared Promise return types (see sdk/src/gateway/types.ts:383–385).
🤖 Prompt for AI Agents
In sdk/src/gateway/client.ts around lines 1053 to 1076, getOutputTokens and
getTokens are implemented as synchronous arrow functions returning arrays but
the types declare Promise return types; update each function to return a Promise
by either marking them async (e.g., const getOutputTokens = async () => { ...;
return tokens.map(...) }) or by wrapping their return values with
Promise.resolve(...) so the implementations match the declared Promise<...>
signatures and preserve the existing mapping logic and types.
sdk/src/gateway/client.ts
Outdated
| const outputTokenAddress = order.outputTokenAddress ?? order.tokensReceived?.[0]?.tokenAddress ?? undefined; | ||
| const outputTokenAmount = order.outputTokenAmount ?? order.tokensReceived?.[0]?.amount ?? undefined; |
There was a problem hiding this comment.
order.tokensReceived?.[0]
I think it should be the last token in the list and not the first one, right?
There was a problem hiding this comment.
It's just a fallback. Ideally we stop using it.
Why should it be the last one?
There was a problem hiding this comment.
Most likely, the last token address represents what the user actually receives.
For example, if a user swaps WBTC → USDC → USDT because Uniswap doesn’t have a direct WBTC → USDT pool, the final transfer event will be for USDT.
This ensures that the last token recorded is indeed what the user ends up holding in their wallet, not just an intermediate step.
There was a problem hiding this comment.
tokensReceived only contains tokens received by the recipient. most of the time it should contains one token, it could contains more if the user receive multiple tokens
|
Update SDK tag as well to |
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
sdk/src/gateway/client.ts(4 hunks)sdk/src/gateway/types.ts(3 hunks)sdk/test/gateway.test.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- sdk/src/gateway/client.ts
- sdk/test/gateway.test.ts
🧰 Additional context used
🧬 Code graph analysis (1)
sdk/src/gateway/types.ts (1)
sdk/src/esplora.ts (1)
EsploraClient(154-517)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: test
| export type OnrampOrder = Omit< | ||
| OnrampOrderResponse, | ||
| 'satsToConvertToEth' | 'orderDetails' | 'tokensReceived' | 'outputTokenAddress' | 'outputTokenAmount' | ||
| > & { | ||
| /** @description The gas refill in satoshis */ | ||
| gasRefill: number; | ||
| /** @description V4 order details */ | ||
| orderDetails?: OrderDetails; | ||
| } & { | ||
| /** @deprecated please use getTokens() instead as gateway v4 can handle multiple tokens */ | ||
| /** @description Get the actual token address received */ | ||
| getTokenAddress(): string | undefined; | ||
| /** @deprecated please use getTokens() instead as gateway v4 can handle multiple tokens */ | ||
| /** @description Get the actual token received */ | ||
| getToken(): Token | undefined; | ||
| /** @deprecated please use getTokens() instead as gateway v4 can handle multiple tokens */ | ||
| /** @description Get the actual amount received of the token */ | ||
| getTokenAmount(): string | number | undefined; | ||
| /** @description Get the number of confirmations */ | ||
| getConfirmations(esploraClient: EsploraClient, latestHeight?: number): Promise<number>; | ||
| /** @description Get the actual order status */ | ||
| getStatus(esploraClient: EsploraClient, latestHeight?: number): Promise<OrderStatus>; | ||
| /** @description Get all the output tokens */ | ||
| getOutputTokens(): { amount: string; token: Token }[]; | ||
| /** @description Get all the tokens */ | ||
| getTokens(): { amount: string | number; token: Token }[]; | ||
| } & GatewayTokensInfo; |
There was a problem hiding this comment.
Expose outputTokenAddress/outputTokenAmount on OnrampOrder.
We Omit both fields from OnrampOrderResponse but never add them back, so the public OnrampOrder type no longer exposes the new output token data. TypeScript consumers can’t compile against order.outputTokenAddress or order.outputTokenAmount, defeating the whole point of “exposing output tokens.” Please reintroduce these members on OnrampOrder (and keep the nullable shapes) so the SDK surface matches the runtime payload.
export type OnrampOrder = Omit<
OnrampOrderResponse,
'satsToConvertToEth' | 'orderDetails' | 'tokensReceived' | 'outputTokenAddress' | 'outputTokenAmount'
> & {
/** @description The gas refill in satoshis */
gasRefill: number;
/** @description V4 order details */
orderDetails?: OrderDetails;
+ /** @description Primary ERC20 token address derived for legacy compatibility */
+ outputTokenAddress: Address | null;
+ /** @description Primary ERC20 token amount derived for legacy compatibility */
+ outputTokenAmount: string | null;
} & {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export type OnrampOrder = Omit< | |
| OnrampOrderResponse, | |
| 'satsToConvertToEth' | 'orderDetails' | 'tokensReceived' | 'outputTokenAddress' | 'outputTokenAmount' | |
| > & { | |
| /** @description The gas refill in satoshis */ | |
| gasRefill: number; | |
| /** @description V4 order details */ | |
| orderDetails?: OrderDetails; | |
| } & { | |
| /** @deprecated please use getTokens() instead as gateway v4 can handle multiple tokens */ | |
| /** @description Get the actual token address received */ | |
| getTokenAddress(): string | undefined; | |
| /** @deprecated please use getTokens() instead as gateway v4 can handle multiple tokens */ | |
| /** @description Get the actual token received */ | |
| getToken(): Token | undefined; | |
| /** @deprecated please use getTokens() instead as gateway v4 can handle multiple tokens */ | |
| /** @description Get the actual amount received of the token */ | |
| getTokenAmount(): string | number | undefined; | |
| /** @description Get the number of confirmations */ | |
| getConfirmations(esploraClient: EsploraClient, latestHeight?: number): Promise<number>; | |
| /** @description Get the actual order status */ | |
| getStatus(esploraClient: EsploraClient, latestHeight?: number): Promise<OrderStatus>; | |
| /** @description Get all the output tokens */ | |
| getOutputTokens(): { amount: string; token: Token }[]; | |
| /** @description Get all the tokens */ | |
| getTokens(): { amount: string | number; token: Token }[]; | |
| } & GatewayTokensInfo; | |
| export type OnrampOrder = Omit< | |
| OnrampOrderResponse, | |
| 'satsToConvertToEth' | 'orderDetails' | 'tokensReceived' | 'outputTokenAddress' | 'outputTokenAmount' | |
| > & { | |
| /** @description The gas refill in satoshis */ | |
| gasRefill: number; | |
| /** @description V4 order details */ | |
| orderDetails?: OrderDetails; | |
| /** @description Primary ERC20 token address derived for legacy compatibility */ | |
| outputTokenAddress: Address | null; | |
| /** @description Primary ERC20 token amount derived for legacy compatibility */ | |
| outputTokenAmount: string | null; | |
| } & { | |
| /** @deprecated please use getTokens() instead as gateway v4 can handle multiple tokens */ | |
| /** @description Get the actual token address received */ | |
| getTokenAddress(): string | undefined; | |
| /** @deprecated please use getTokens() instead as gateway v4 can handle multiple tokens */ | |
| /** @description Get the actual token received */ | |
| getToken(): Token | undefined; | |
| /** @deprecated please use getTokens() instead as gateway v4 can handle multiple tokens */ | |
| /** @description Get the actual amount received of the token */ | |
| getTokenAmount(): string | number | undefined; | |
| /** @description Get the number of confirmations */ | |
| getConfirmations(esploraClient: EsploraClient, latestHeight?: number): Promise<number>; | |
| /** @description Get the actual order status */ | |
| getStatus(esploraClient: EsploraClient, latestHeight?: number): Promise<OrderStatus>; | |
| /** @description Get all the output tokens */ | |
| getOutputTokens(): { amount: string; token: Token }[]; | |
| /** @description Get all the tokens */ | |
| getTokens(): { amount: string | number; token: Token }[]; | |
| } & GatewayTokensInfo; |
🤖 Prompt for AI Agents
In sdk/src/gateway/types.ts around lines 359 to 385, the OnrampOrder type
Omit'ed outputTokenAddress and outputTokenAmount but never reintroduces them, so
consumers cannot access those fields; add them back to the merged type with
nullable shapes (e.g. outputTokenAddress?: string | null; outputTokenAmount?:
string | number | null) and include short JSDoc comments matching runtime
payload expectations so the public SDK surface matches the runtime data.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
sdk/src/gateway/types.ts (1)
376-402: Previously flagged:outputTokenAddressandoutputTokenAmountnot exposed onOnrampOrder.A previous review comment identified that these fields are omitted from
OnrampOrderResponsebut never reintroduced on theOnrampOrdertype, preventing TypeScript consumers from accessing them directly as properties (e.g.,order.outputTokenAddress). The current implementation only provides method-based access through deprecated getters, which may not fully address the original concern.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
sdk/src/gateway/client.ts(4 hunks)sdk/src/gateway/types.ts(3 hunks)sdk/test/gateway.test.ts(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- sdk/src/gateway/client.ts
🧰 Additional context used
🧬 Code graph analysis (2)
sdk/src/gateway/types.ts (1)
sdk/src/esplora.ts (1)
EsploraClient(154-517)
sdk/test/gateway.test.ts (1)
sdk/src/gateway/client.ts (1)
MAINNET_GATEWAY_BASE_URL(69-69)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: test
🔇 Additional comments (1)
sdk/test/gateway.test.ts (1)
501-601: Excellent test coverage for multiple output token scenarios.This test comprehensively validates the new
getOutputTokens()andgetTokens()methods across three distinct order states (pending, gateway v3, gateway v4), including proper handling oftokensReceiveddata and legacy fallbacks.
mastilver
force-pushed
the
feat/gateway-v4-expose-output-tokens
branch
from
8abf1dc to
c40eb9a
Compare
Summary by CodeRabbit
New Features
Public API
Bug Fixes
Tests
Chore