fix: ton tx history parsing #11727
fix: ton tx history parsing #11727
Conversation
…unknown - Changed parseTx parameter from `msgHash: string` to `txHashOrTx: unknown` - Added type checking to convert unknown to string for use - Follows the pattern established in TronChainAdapter.ts Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…te parse - Add TonTx and TonTxMessage types to packages/chain-adapters/src/ton/types.ts - Create private parse() helper method in TonChainAdapter.ts following Tron and SecondClassEvmAdapter patterns - parse() method handles: - Transaction status determination (aborted/success) - Transfer direction detection (send/receive) - Building transfers array from in_msg and out_msgs - Returning properly structured Transaction object - Update parseTx() to call parse() after fetching transaction data - Improve error handling when transaction is not found Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…dle TON token transfers - Add parseJettonTransfers method to fetch and parse Jetton transfers from Toncenter v3 API - Update parseTx to include Jetton transfers in transaction data - Use address_book to convert raw addresses to user-friendly format - Support both send and receive transfer types for Jettons Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…e import - Removed unused TonTxMessage type import from TonChainAdapter.ts - Lint check passes - Package build succeeds (all 8 packages compile) - Full type-check requires Java for OpenAPI generator (pre-existing infrastructure requirement) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
📝 WalkthroughWalkthroughThis PR implements transaction history retrieval for the TON chain adapter, including batching and pagination support. It adds jetton (TON token) transfer parsing and address normalization, refactors the public Changes
Sequence Diagram(s)sequenceDiagram
actor Client
participant getTxHistory
participant requestQueue
participant parseTx
participant parseJettonTransfers
participant addressBook
Client->>getTxHistory: getTxHistory(input)
activate getTxHistory
getTxHistory->>getTxHistory: Initialize cursor & pagination
loop Until no more results
getTxHistory->>requestQueue: Queue fetch request
requestQueue->>requestQueue: Fetch transactions (cursor, pageSize)
requestQueue-->>getTxHistory: txs array
loop For each transaction
getTxHistory->>parseTx: parseTx(tx, pubkey)
activate parseTx
parseTx->>parse: parse(tx, pubkey, txid)
activate parse
parse->>addressBook: Normalize in_msg/out_msgs
addressBook-->>parse: Resolved addresses
parse-->>parseTx: Transaction with transfers
deactivate parse
parseTx->>parseJettonTransfers: parseJettonTransfers(txHash, pubkey)
activate parseJettonTransfers
parseJettonTransfers-->>parseTx: Jetton transfers
deactivate parseJettonTransfers
parseTx-->>getTxHistory: Combined transaction
deactivate parseTx
end
getTxHistory->>getTxHistory: Update cursor
end
getTxHistory-->>Client: TxHistoryResponse
deactivate getTxHistory
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20-25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
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 |
…n-t-parsing-txs-properly-
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Fix all issues with AI agents
In `@packages/chain-adapters/src/ton/TonChainAdapter.ts`:
- Around line 443-447: Validate the incoming cursor before converting to an
offset: in the scope where cursor and offset are initialized (used by
fetchTxHistory), check that cursor is a valid numeric string (e.g., digits only
or Number.isFinite(Number(cursor))) and only then set offset = parseInt(cursor,
10); otherwise default offset to 0 (or handle invalid cursor explicitly). Update
the initialization around the cursor/offset variables so offset cannot become
NaN and ensure fetchTxHistory uses this validated offset.
- Around line 796-872: The catch block in the jetton transfer fetch silently
swallows errors; change the try/catch around the this.httpApiRequest call in
TonChainAdapter (the loop handling response.jetton_transfers and using
addressesMatch, toAssetId, and TransferType) to catch the error as a variable
and log a clear contextual error (include txHash and pubkey and the error/stack)
via the adapter logger (e.g., this.logger.error or existing logging facility)
before returning [] so failures are recorded for debugging.
- Around line 960-963: The parseTx method currently coerces non-string inputs to
"[object Object]" causing API failures; update parseTx to either accept only
string hashes by changing its signature to parseTx(txHash: string, pubkey:
string): Promise<Transaction> and remove the fallback conversion, or add an
explicit type guard branch for TonTx objects (e.g., detect TonTx and extract its
hash or required fields) similar to the TRON/SUI pattern; modify the function
body around parseTx and any callers to pass a string hash (or handle TonTx) and
ensure types Transaction and TonTx are used consistently.
- Around line 891-893: The code lowercases addresses when comparing
tx.in_msg.destination, tx.in_msg.source, and pubkey which corrupts user-friendly
base64 TON addresses; update the normalization used by addressesMatch (or the
caller) so only raw TON addresses (e.g., addresses that start with "0:" or are
hex/raw forms) are converted to lowercase, while base64/user-friendly addresses
are left unchanged; implement this by adding a small discriminator (raw-address
pattern vs base64 pattern) and applying .toLowerCase() only for the raw path
before comparing in addressesMatch.
| const { pubkey, cursor, pageSize = 25, requestQueue, knownTxIds } = input | ||
|
|
||
| const offset = cursor ? parseInt(cursor, 10) : 0 | ||
|
|
||
| const fetchTxHistory = async () => { |
There was a problem hiding this comment.
Validate cursor before building the offset.
A non-numeric cursor yields offset=NaN, which breaks the request.
🛠️ Proposed fix
- const offset = cursor ? parseInt(cursor, 10) : 0
+ const offset = cursor ? Number.parseInt(cursor, 10) : 0
+ if (!Number.isFinite(offset) || offset < 0) {
+ throw new Error('cursor must be a non-negative integer')
+ }📝 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.
| const { pubkey, cursor, pageSize = 25, requestQueue, knownTxIds } = input | |
| const offset = cursor ? parseInt(cursor, 10) : 0 | |
| const fetchTxHistory = async () => { | |
| const { pubkey, cursor, pageSize = 25, requestQueue, knownTxIds } = input | |
| const offset = cursor ? Number.parseInt(cursor, 10) : 0 | |
| if (!Number.isFinite(offset) || offset < 0) { | |
| throw new Error('cursor must be a non-negative integer') | |
| } | |
| const fetchTxHistory = async () => { |
🤖 Prompt for AI Agents
In `@packages/chain-adapters/src/ton/TonChainAdapter.ts` around lines 443 - 447,
Validate the incoming cursor before converting to an offset: in the scope where
cursor and offset are initialized (used by fetchTxHistory), check that cursor is
a valid numeric string (e.g., digits only or Number.isFinite(Number(cursor)))
and only then set offset = parseInt(cursor, 10); otherwise default offset to 0
(or handle invalid cursor explicitly). Update the initialization around the
cursor/offset variables so offset cannot become NaN and ensure fetchTxHistory
uses this validated offset.
| try { | ||
| const response = await this.httpApiRequest<{ | ||
| jetton_transfers?: { | ||
| source?: string | ||
| destination?: string | ||
| amount?: string | ||
| jetton_master?: string | ||
| }[] | ||
| address_book?: Record<string, { user_friendly: string }> | ||
| }>(`/api/v3/jetton/transfers?tx_hash=${encodeURIComponent(txHash)}`) | ||
|
|
||
| if (!response.jetton_transfers || response.jetton_transfers.length === 0) { | ||
| return [] | ||
| } | ||
|
|
||
| const transfers: { | ||
| assetId: string | ||
| from: string[] | ||
| to: string[] | ||
| type: TransferType | ||
| value: string | ||
| }[] = [] | ||
|
|
||
| const addressBook = response.address_book ?? {} | ||
|
|
||
| for (const transfer of response.jetton_transfers) { | ||
| if ( | ||
| !transfer.source || | ||
| !transfer.destination || | ||
| !transfer.amount || | ||
| !transfer.jetton_master | ||
| ) { | ||
| continue | ||
| } | ||
|
|
||
| const sourceUserFriendly = addressBook[transfer.source]?.user_friendly ?? transfer.source | ||
| const destUserFriendly = | ||
| addressBook[transfer.destination]?.user_friendly ?? transfer.destination | ||
| const jettonUserFriendly = | ||
| addressBook[transfer.jetton_master]?.user_friendly ?? transfer.jetton_master | ||
|
|
||
| const isSend = this.addressesMatch(sourceUserFriendly, pubkey) | ||
| const isReceive = this.addressesMatch(destUserFriendly, pubkey) | ||
|
|
||
| if (!isSend && !isReceive) continue | ||
|
|
||
| const assetId = toAssetId({ | ||
| chainId: this.chainId, | ||
| assetNamespace: 'jetton', | ||
| assetReference: jettonUserFriendly, | ||
| }) | ||
|
|
||
| if (isSend) { | ||
| transfers.push({ | ||
| assetId, | ||
| from: [sourceUserFriendly], | ||
| to: [destUserFriendly], | ||
| type: TransferType.Send, | ||
| value: transfer.amount, | ||
| }) | ||
| } | ||
|
|
||
| if (isReceive) { | ||
| transfers.push({ | ||
| assetId, | ||
| from: [sourceUserFriendly], | ||
| to: [destUserFriendly], | ||
| type: TransferType.Receive, | ||
| value: transfer.amount, | ||
| }) | ||
| } | ||
| } | ||
|
|
||
| return transfers | ||
| } catch { | ||
| return [] | ||
| } |
There was a problem hiding this comment.
Don’t silently swallow Jetton transfer fetch failures.
Returning [] without logging hides partial history issues and makes debugging hard.
🛠️ Proposed fix
- } catch {
- return []
- }
+ } catch (err) {
+ console.error('[TON] Error fetching jetton transfers', { txHash, pubkey, err })
+ return []
+ }🤖 Prompt for AI Agents
In `@packages/chain-adapters/src/ton/TonChainAdapter.ts` around lines 796 - 872,
The catch block in the jetton transfer fetch silently swallows errors; change
the try/catch around the this.httpApiRequest call in TonChainAdapter (the loop
handling response.jetton_transfers and using addressesMatch, toAssetId, and
TransferType) to catch the error as a variable and log a clear contextual error
(include txHash and pubkey and the error/stack) via the adapter logger (e.g.,
this.logger.error or existing logging facility) before returning [] so failures
are recorded for debugging.
| const isReceive = this.addressesMatch(tx.in_msg.destination, pubkey) | ||
| const isSend = this.addressesMatch(tx.in_msg.source, pubkey) | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's find and examine the TonChainAdapter.ts file
fd "TonChainAdapter.ts" --type fRepository: shapeshift/web
Length of output: 108
🏁 Script executed:
# Once we find the file, let's look at the specific lines mentioned
# Lines 891-893 and 919-921
head -n 925 packages/chain-adapters/src/ton/TonChainAdapter.ts | tail -n +880Repository: shapeshift/web
Length of output: 1494
🏁 Script executed:
# Let's also look at the normalizeAddress method implementation
cat -n packages/chain-adapters/src/ton/TonChainAdapter.ts | grep -A 10 "normalizeAddress"Repository: shapeshift/web
Length of output: 619
🏁 Script executed:
# Check how addressesMatch is implemented
cat -n packages/chain-adapters/src/ton/TonChainAdapter.ts | grep -B 5 -A 10 "addressesMatch"Repository: shapeshift/web
Length of output: 2814
🏁 Script executed:
# Look for where pubkey comes from and what format it's in
cd packages/chain-adapters/src/ton && grep -B 20 "parseNormalTransfers" TonChainAdapter.ts | head -50Repository: shapeshift/web
Length of output: 40
🏁 Script executed:
# Check the function signature that calls parseNormalTransfers
grep -B 5 "parseNormalTransfers\|private parseNormalTransfers" packages/chain-adapters/src/ton/TonChainAdapter.tsRepository: shapeshift/web
Length of output: 40
🏁 Script executed:
# Look for TX type definition to understand the address format
grep -A 30 "interface.*Tx\|type.*Tx" packages/chain-adapters/src/ton/TonChainAdapter.ts | head -50Repository: shapeshift/web
Length of output: 1364
🏁 Script executed:
# Check if there are any tests for address matching
find . -name "*.test.ts" -o -name "*.spec.ts" | xargs grep -l "TonChainAdapter\|addressesMatch" 2>/dev/null | head -5Repository: shapeshift/web
Length of output: 208
🏁 Script executed:
# Look for TON address format documentation or types from the API
grep -r "user_friendly\|address_book" packages/chain-adapters/src/ton/ --include="*.ts"Repository: shapeshift/web
Length of output: 2676
🏁 Script executed:
# Let's look at the full parseNormalTransfers method to understand what format addresses are in
sed -n '860,945p' packages/chain-adapters/src/ton/TonChainAdapter.tsRepository: shapeshift/web
Length of output: 2583
🏁 Script executed:
# Check how pubkey parameter is obtained/formatted
sed -n '750,800p' packages/chain-adapters/src/ton/TonChainAdapter.tsRepository: shapeshift/web
Length of output: 1289
🏁 Script executed:
# Look for where pubkey comes from and its source
grep -B 10 "parseNormalTransfers\|parseJettonTransfers" packages/chain-adapters/src/ton/TonChainAdapter.ts | grep -A 5 "pubkey\|getPublicKey"Repository: shapeshift/web
Length of output: 490
🏁 Script executed:
# Check what format the tx data comes in from the API response
sed -n '700,750p' packages/chain-adapters/src/ton/TonChainAdapter.tsRepository: shapeshift/web
Length of output: 1103
🏁 Script executed:
# Find the method signatures that call parse() and parseJettonTransfers() to see where pubkey comes from
grep -B 30 "private parse(" packages/chain-adapters/src/ton/TonChainAdapter.ts | grep -E "async|pubkey|getPublicKey" | head -20Repository: shapeshift/web
Length of output: 129
🏁 Script executed:
# Look for public methods that take transactions and use pubkey
sed -n '600,750p' packages/chain-adapters/src/ton/TonChainAdapter.tsRepository: shapeshift/web
Length of output: 3925
🏁 Script executed:
# Search for where this.parse is called
grep -B 5 "this\.parse(" packages/chain-adapters/src/ton/TonChainAdapter.tsRepository: shapeshift/web
Length of output: 457
🏁 Script executed:
# Check if there's any type definition for TonTx and what tx addresses look like
grep -r "type TonTx\|interface TonTx" packages/chain-adapters/src/ton/ --include="*.ts"Repository: shapeshift/web
Length of output: 270
🏁 Script executed:
# Look at the types file to understand address formats
head -100 packages/chain-adapters/src/ton/types.tsRepository: shapeshift/web
Length of output: 1372
🏁 Script executed:
# Find the methods that call this.parse() to understand where pubkey comes from
grep -B 50 "this\.parse\(normalizedTx, pubkey" packages/chain-adapters/src/ton/TonChainAdapter.ts | head -80Repository: shapeshift/web
Length of output: 81
🏁 Script executed:
# Look for where these methods are called to understand the full flow
grep -r "getTxHistory\|getTransaction" packages/chain-adapters/src/ton/TonChainAdapter.ts | head -20Repository: shapeshift/web
Length of output: 256
🏁 Script executed:
# Check the getTxHistory signature and implementation
sed -n '500,650p' packages/chain-adapters/src/ton/TonChainAdapter.tsRepository: shapeshift/web
Length of output: 4089
🏁 Script executed:
# Let's find the full getTxHistory method signature and see what pubkey format is
sed -n '465,530p' packages/chain-adapters/src/ton/TonChainAdapter.tsRepository: shapeshift/web
Length of output: 2026
🏁 Script executed:
# Look for where getTxHistory is called to understand what pubkey format is passed
grep -r "getTxHistory" packages/chain-adapters/src/ton/ --include="*.ts" -B 3 -A 3 | head -40Repository: shapeshift/web
Length of output: 1118
🏁 Script executed:
# Search for getAddress to see what format addresses are in
grep -B 5 -A 15 "async getAddress" packages/chain-adapters/src/ton/TonChainAdapter.tsRepository: shapeshift/web
Length of output: 634
🏁 Script executed:
# Look at the full normalizedTx construction in getTxHistory
sed -n '465,570p' packages/chain-adapters/src/ton/TonChainAdapter.tsRepository: shapeshift/web
Length of output: 2990
🏁 Script executed:
# Look for TON address format documentation or examples in tests
find . -name "*.test.ts" -o -name "*.spec.ts" | xargs grep -l "ton\|Ton" 2>/dev/null | head -3Repository: shapeshift/web
Length of output: 261
🏁 Script executed:
# Search for any TON address format validation or examples
grep -r "0:[0-9a-fA-F]" packages/chain-adapters/src/ton/ --include="*.ts"Repository: shapeshift/web
Length of output: 40
🏁 Script executed:
# Check if there are examples of base64 addresses being used
grep -r "user_friendly" packages/chain-adapters/src/ton/ --include="*.ts" -B 2 -A 2 | head -50Repository: shapeshift/web
Length of output: 4289
🏁 Script executed:
# Look for TON documentation or address format comments
grep -r "base64\|user.friendly\|address" packages/chain-adapters/src/ton/TonChainAdapter.ts | grep -i "comment\|//"Repository: shapeshift/web
Length of output: 40
🏁 Script executed:
# Understand the actual flow: when are user-friendly vs raw addresses used?
sed -n '820,850p' packages/chain-adapters/src/ton/TonChainAdapter.tsRepository: shapeshift/web
Length of output: 1059
🏁 Script executed:
# Let's understand what formats pubkey and addresses can be by checking how getAddress returns them
sed -n '390,425p' packages/chain-adapters/src/ton/TonChainAdapter.tsRepository: shapeshift/web
Length of output: 975
🏁 Script executed:
# Check if there are real examples of base64 user-friendly TON addresses being used
grep -r "EQAB\|EQC\|EQD" packages/ --include="*.ts" --include="*.json" | head -10Repository: shapeshift/web
Length of output: 50371
🏁 Script executed:
# Verify the actual API response to see what format addresses come in
grep -B 10 -A 10 "address_book\[" packages/chain-adapters/src/ton/TonChainAdapter.ts | head -40Repository: shapeshift/web
Length of output: 40
🌐 Web query:
TON blockchain user-friendly address format base64 case-sensitive
💡 Result:
Short answer: TON "user-friendly" addresses are a 36-byte binary structure encoded as 48 characters using standard Base64 or URL‑safe Base64 — so they are case‑sensitive (A–Z and a–z are distinct). The 36 bytes = 1 byte flags (bounce/testnet/etc.), 1 byte workchain id, 32 bytes account id, and 2 bytes CRC16 checksum; both base64 and base64url encodings are valid and must be supported. [1][2]
Sources:
- TON docs — Internal (user‑friendly) address format. [1].
- TON docs — Quick start / reading from network (base64/base64url examples). [2]. (docs.ton.org)
Citations:
- 1: https://docs.ton.org/v3/documentation/smart-contracts/addresses/address-formats?utm_source=openai
🏁 Script executed:
# Check if pubkey is consistently in a specific format by looking at how it's obtained
sed -n '440,480p' packages/chain-adapters/src/ton/TonChainAdapter.tsRepository: shapeshift/web
Length of output: 1237
🏁 Script executed:
# Look for how getTxHistory is called to see what format pubkey has
grep -r "getTxHistory" packages/ --include="*.ts" -B 2 -A 2 | head -30Repository: shapeshift/web
Length of output: 2501
Only normalize case for raw TON addresses, not user-friendly base64 addresses.
User-friendly TON addresses use base64 encoding where case is semantically significant—lowercasing them corrupts the decoded binary value and causes address matching to fail. Only raw addresses (format 0: or raw hex) should be lowercased.
Proposed fix
private normalizeAddress(address: string): string {
if (!address) return ''
const rawAddressRegex = /^-?\d+:[0-9a-fA-F]{64}$/
if (rawAddressRegex.test(address)) return address.replace(/^0:/, '').toLowerCase()
return address
}🤖 Prompt for AI Agents
In `@packages/chain-adapters/src/ton/TonChainAdapter.ts` around lines 891 - 893,
The code lowercases addresses when comparing tx.in_msg.destination,
tx.in_msg.source, and pubkey which corrupts user-friendly base64 TON addresses;
update the normalization used by addressesMatch (or the caller) so only raw TON
addresses (e.g., addresses that start with "0:" or are hex/raw forms) are
converted to lowercase, while base64/user-friendly addresses are left unchanged;
implement this by adding a small discriminator (raw-address pattern vs base64
pattern) and applying .toLowerCase() only for the raw path before comparing in
addressesMatch.
| async parseTx(txHashOrTx: unknown, pubkey: string): Promise<Transaction> { | ||
| try { | ||
| const msgHash = typeof txHashOrTx === 'string' ? txHashOrTx : String(txHashOrTx) | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# First, find the TonChainAdapter.ts file and check its location
find . -name "TonChainAdapter.ts" -type fRepository: shapeshift/web
Length of output: 110
🏁 Script executed:
#!/bin/bash
# Once we have the file, let's look at lines 960-963 and surrounding context
sed -n '950,975p' packages/chain-adapters/src/ton/TonChainAdapter.ts | cat -nRepository: shapeshift/web
Length of output: 1071
🏁 Script executed:
#!/bin/bash
# Search for parseTx call sites in the codebase
rg -nP --type=ts '\.(parseTx|parseTx\s*\()' | head -30Repository: shapeshift/web
Length of output: 3394
🏁 Script executed:
#!/bin/bash
# Check what TonTx type looks like and where it's defined
rg -nP --type=ts 'type TonTx|interface TonTx' | head -10Repository: shapeshift/web
Length of output: 280
🏁 Script executed:
#!/bin/bash
# Let's also look at the TronChainAdapter for comparison since there's a learning about it
find . -name "TronChainAdapter.ts" -type f -exec sed -n '560,600p' {} +Repository: shapeshift/web
Length of output: 1234
🏁 Script executed:
#!/bin/bash
# Check the TonTx type definition
cat packages/chain-adapters/src/ton/types.ts | head -80Repository: shapeshift/web
Length of output: 1372
🏁 Script executed:
#!/bin/bash
# Check the useTxDetails.ts call site at line 221
sed -n '210,230p' src/hooks/useTxDetails/useTxDetails.ts | cat -nRepository: shapeshift/web
Length of output: 764
🏁 Script executed:
#!/bin/bash
# Get more context around useTxDetails to understand what 'tx' is
sed -n '200,240p' src/hooks/useTxDetails/useTxDetails.ts | cat -nRepository: shapeshift/web
Length of output: 1414
🏁 Script executed:
#!/bin/bash
# Check if TON adapter has httpProvider and what getTransaction returns
find . -name "TonChainAdapter.ts" -type f -exec grep -A 5 "httpProvider\|getTransaction" {} + | head -40Repository: shapeshift/web
Length of output: 261
🏁 Script executed:
#!/bin/bash
# Check TonChainAdapter constructor and provider setup
sed -n '1,100p' packages/chain-adapters/src/ton/TonChainAdapter.ts | cat -nRepository: shapeshift/web
Length of output: 3812
🏁 Script executed:
#!/bin/bash
# Look for unchained ton client to see what getTransaction returns
rg -nP --type=ts "unchained.*ton|ton.*client" packages/chain-adapters/src/ton/ | head -20Repository: shapeshift/web
Length of output: 40
🏁 Script executed:
#!/bin/bash
# Check if TON adapter internally calls parseTx with objects (e.g., in subscriptions or polling)
sed -n '900,1100p' packages/chain-adapters/src/ton/TonChainAdapter.ts | cat -nRepository: shapeshift/web
Length of output: 5493
🏁 Script executed:
#!/bin/bash
# Check if there are any TON-specific calls that might pass TonTx objects
rg -nP --type=ts "\.parseTx.*\(" packages/chain-adapters/src/ton/Repository: shapeshift/web
Length of output: 40
🏁 Script executed:
#!/bin/bash
# Get full parseTx implementation in TonChainAdapter to see if it ever handles object inputs
sed -n '960,1050p' packages/chain-adapters/src/ton/TonChainAdapter.ts | cat -nRepository: shapeshift/web
Length of output: 3365
🏁 Script executed:
#!/bin/bash
# Check the base ChainAdapter interface to see parseTx signature
rg -nP "interface IChainAdapter|parseTx.*unknown" packages/chain-adapters/src/api.ts | head -20Repository: shapeshift/web
Length of output: 121
🏁 Script executed:
#!/bin/bash
# Check if other adapters use 'unknown' for parseTx parameter
rg -nP "async parseTx.*unknown" packages/chain-adapters/src/Repository: shapeshift/web
Length of output: 589
🏁 Script executed:
#!/bin/bash
# Check TRON adapter actual implementation to compare
sed -n '560,600p' packages/chain-adapters/src/tron/TronChainAdapter.ts | cat -nRepository: shapeshift/web
Length of output: 1521
🏁 Script executed:
#!/bin/bash
# Get the full TRON parseTx implementation to see how it handles objects
sed -n '592,650p' packages/chain-adapters/src/tron/TronChainAdapter.ts | cat -nRepository: shapeshift/web
Length of output: 2169
🏁 Script executed:
#!/bin/bash
# Check SUI adapter implementation
sed -n '600,650p' packages/chain-adapters/src/sui/SuiChainAdapter.ts | cat -nRepository: shapeshift/web
Length of output: 2192
Handle TonTx object inputs explicitly, or restrict to string hashes.
The current implementation converts objects to "[object Object]", causing silent API lookup failures. Either add explicit type-guard branching to handle TonTx objects (following the TRON/SUI pattern), or change the signature to parseTx(txHash: string, ...) to restrict inputs to hashes only. All call sites currently pass strings, so restricting the signature may be simpler.
🤖 Prompt for AI Agents
In `@packages/chain-adapters/src/ton/TonChainAdapter.ts` around lines 960 - 963,
The parseTx method currently coerces non-string inputs to "[object Object]"
causing API failures; update parseTx to either accept only string hashes by
changing its signature to parseTx(txHash: string, pubkey: string):
Promise<Transaction> and remove the fallback conversion, or add an explicit type
guard branch for TonTx objects (e.g., detect TonTx and extract its hash or
required fields) similar to the TRON/SUI pattern; modify the function body
around parseTx and any callers to pass a string hash (or handle TonTx) and
ensure types Transaction and TonTx are used consistently.
Description
Fixes the TON tx parsing upserted into history, which wasn't working at all previously
Issue (if applicable)
closes #
Risk
Testing
Engineering
Operations
Screenshots (if applicable)
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.