@exodus/solana-api 2.0.8 → 2.0.10

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/package.json +3 -3
  2. package/src/api.js +12 -1
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@exodus/solana-api",
3
- "version": "2.0.8",
3
+ "version": "2.0.10",
4
4
  "description": "Exodus internal Solana asset API wrapper",
5
5
  "main": "src/index.js",
6
6
  "files": [
@@ -19,7 +19,7 @@
19
19
  "@exodus/assets-base": "^8.0.139",
20
20
  "@exodus/models": "^8.7.2",
21
21
  "@exodus/nfts-core": "^0.5.0",
22
- "@exodus/solana-lib": "^1.3.13",
22
+ "@exodus/solana-lib": "^1.3.14",
23
23
  "bn.js": "^4.11.0",
24
24
  "lodash": "^4.17.11",
25
25
  "url-join": "4.0.0",
@@ -28,5 +28,5 @@
28
28
  "devDependencies": {
29
29
  "node-fetch": "~2.6.0"
30
30
  },
31
- "gitHead": "12104775b7a98f110b78e928321ca0d530757d88"
31
+ "gitHead": "319f5292a7b3e06d230a571c109f6d7d40423ff8"
32
32
  }
package/src/api.js CHANGED
@@ -257,13 +257,24 @@ export class Api {
257
257
  // This is not perfect as there could be multiple same-token transfers in single
258
258
  // transaction, but our wallet only supports one transaction with single txId
259
259
  // so we are picking first that matches (correct token + type - send or receive)
260
- const { from, to, owner } = innerInstructions.find((inner) => {
260
+ const match = innerInstructions.find((inner) => {
261
261
  const targetOwner = amount.isNeg() ? ownerAddress : null
262
262
  return (
263
263
  inner.token.mintAddress === tokenAccount.mintAddress && targetOwner === inner.owner
264
264
  )
265
265
  })
266
266
 
267
+ // It's possible we won't find a match, because our innerInstructions only contain
268
+ // spl-token transfers, but balances of SPL tokens can change in different ways too.
269
+ // for now, we are ignoring this to simplify as those cases are not that common, but
270
+ // they should be handled eventually. It was already a scretch to add unparsed txs logic
271
+ // to existing parser, expanding it further is not going to end well.
272
+ // this probably should be refactored from ground to handle all those transactions
273
+ // as a core part of it in the future
274
+ if (!match) return null
275
+
276
+ const { from, to, owner } = match
277
+
267
278
  return {
268
279
  id: txDetails.transaction.signatures[0],
269
280
  slot: txDetails.slot,