feat: add collection data - #30
Conversation
WalkthroughThe update introduces asynchronous fetching and decoding of NFT collection metadata throughout the codebase. Decoders for NFT mint, burn, and IBC transfer messages now retrieve and return detailed collection information, enriching interfaces and test fixtures accordingly. New Zod schemas and type definitions for collections are added, and tests are updated to validate the expanded metadata. Changes
Sequence Diagram(s)sequenceDiagram
participant Decoder as Decoder (Mint/Burn/IBC)
participant ApiClient
participant CollectionAPI
participant NFTAPI
Decoder->>ApiClient: findCollectionFromCollectionAddr(collectionAddr)
ApiClient->>CollectionAPI: GET /accounts/{collectionAddr}/resources
CollectionAPI-->>ApiClient: Collection resource data
ApiClient-->>Decoder: Parsed CollectionResource or null
alt Mint Decoder
Decoder->>ApiClient: findNftFromTokenAddr(tokenAddr)
ApiClient->>NFTAPI: GET /accounts/{tokenAddr}/resources
NFTAPI-->>ApiClient: NFT resource data
ApiClient-->>Decoder: Parsed NFT data
end
Decoder-->>Caller: Decoded message with detailed collection metadata
Poem
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (6)
src/api.ts (1)
32-46: LGTM: Well-implemented collection metadata fetching method.The new
findCollectionFromCollectionAddrmethod follows the established patterns in the ApiClient class with proper error handling, null checks, and Zod schema validation. The implementation correctly searches for the"0x1::collection::Collection"struct tag and returns typed results.Consider the performance implications when this method is called for multiple tokens simultaneously, as noted in the metadata resolver where it's used in a Promise.allSettled pattern.
src/metadata-resolver.ts (1)
14-25: LGTM: Proper sequential fetching of NFT and collection metadata.The implementation correctly fetches NFT metadata first, then uses the collection address to fetch collection details. The Promise.allSettled approach ensures all token addresses are processed even if individual requests fail.
Consider the performance impact of making two API calls per token address. For scenarios with many tokens, you might want to implement batching or caching strategies to reduce API load.
src/decoders/ibc/nft.ts (1)
119-126: Consider standardizing error message format.The error message format is slightly different from the send decoder. Consider using a consistent format across both decoders.
- `Collection data not found for collection address ${collection_id}` + `Collection data not found for collection address ${toBech32(collection_id)}`src/decoders/move/nft.ts (2)
48-49: Consider adding error handling for NFT data fetching.The NFT data fetching doesn't include error handling like the collection data fetching. While this might be intentional (since
tokenUriis optional), consider whether consistency in error handling would be beneficial.If error handling is needed, you could add:
const nftData = await apiClient.findNftFromTokenAddr(mintEvent.nft); +if (!nftData) { + throw new Error( + `NFT data not found for token address ${mintEvent.nft}` + ); +}
63-64: Misleading comment placement.The comment "in case of burn, the tokenUri is not available" appears in the mint decoder, which is confusing. Consider updating the comment to better reflect its purpose in the mint context.
- // in case of burn, the tokenUri is not available + // tokenUri is optional and may not be available tokenUri: nftData?.data.uri,src/tests/ibc/receive-nft.test.ts (1)
24-89: Consider adding error scenario test coverage.The tests comprehensively cover successful scenarios but don't test error cases such as when collection data is not found. This would help ensure the error handling in the decoders works as expected.
Consider adding test cases like:
it("should throw error when collection data is not found", async () => { // Setup mock to return null for collection data const mockApiResponses = { ...mockApiResponsesForIbcReceiveNftSourceToken, // Override collection response to return null }; setupMockApi(mockedAxios, mockApiResponses); await expect(decoder.decodeTransaction(mockMsgIbcReceiveNftSourceToken)) .rejects.toThrow("Collection data not found"); });Also applies to: 93-180
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Lite
📒 Files selected for processing (17)
src/api.ts(2 hunks)src/decoders/ibc/nft.ts(4 hunks)src/decoders/move/nft.ts(4 hunks)src/interfaces/decoded-messages.ts(4 hunks)src/interfaces/metadata.ts(1 hunks)src/metadata-resolver.ts(1 hunks)src/schema/resources.ts(1 hunks)src/tests/fixtures/ibc/receive-nft.fixture.ts(3 hunks)src/tests/fixtures/ibc/send-nft.fixture.ts(1 hunks)src/tests/fixtures/move/nft-burn.fixture.ts(1 hunks)src/tests/fixtures/move/nft-mint.fixture.ts(1 hunks)src/tests/fixtures/move/object-transfer.fixture.ts(1 hunks)src/tests/ibc/receive-nft.test.ts(5 hunks)src/tests/ibc/send-nft.test.ts(3 hunks)src/tests/move/nft-burn.test.ts(1 hunks)src/tests/move/nft-mint.test.ts(2 hunks)src/tests/move/object-transfer.test.ts(1 hunks)
🧰 Additional context used
🧠 Learnings (15)
📓 Common learnings
Learnt from: evilpeach
PR: initia-labs/tx-decoder#28
File: src/metadata-resolver.ts:27-32
Timestamp: 2025-07-03T01:32:16.425Z
Learning: In the tx-decoder project, Zod is used for data validation at the input layer, which means direct property access is safe in functions like `resolveMetadata` since the data structure is already validated. Optional chaining is not needed in such cases.
src/tests/move/object-transfer.test.ts (1)
Learnt from: evilpeach
PR: initia-labs/tx-decoder#28
File: src/metadata-resolver.ts:27-32
Timestamp: 2025-07-03T01:32:16.425Z
Learning: In the tx-decoder project, Zod is used for data validation at the input layer, which means direct property access is safe in functions like `resolveMetadata` since the data structure is already validated. Optional chaining is not needed in such cases.
src/schema/resources.ts (2)
Learnt from: ALPAC-4
PR: initia-labs/initia-registry#274
File: _packages/types/src/zods/Profile.ts:38-43
Timestamp: 2025-02-06T07:15:49.671Z
Learning: The TypeScript types and Zod schemas in `_packages/types/src/types/` and `_packages/types/src/zods/` are auto-generated from JSON Schema files in the root directory using json-schema-to-typescript and json-schema-to-zod libraries. Changes should be made to the source schema files, not the generated code.
Learnt from: ALPAC-4
PR: initia-labs/initia-registry#274
File: _packages/types/src/zods/Profile.ts:12-17
Timestamp: 2025-02-06T07:15:46.189Z
Learning: The TypeScript types and Zod schemas in `@initia/initia-registry-types` package are auto-generated from JSON Schema files in the root directory. Modifications should be made to the schema files rather than the generated code.
src/tests/move/nft-mint.test.ts (3)
Learnt from: joon9823
PR: initia-labs/initia.js#81
File: src/core/Msg.ts:518-521
Timestamp: 2024-10-08T18:48:55.677Z
Learning: In `src/core/Msg.ts`, within the `fromAmino` function, the type identifiers for `MsgUpdateIbcPermAdmin` and `MsgUpdatePermissionedRelayers` should use the prefix `'ibc-perm/'` as the valid identifier.
Learnt from: joon9823
PR: initia-labs/initia.js#81
File: src/core/Msg.ts:518-521
Timestamp: 2024-10-07T09:09:55.619Z
Learning: In `src/core/Msg.ts`, within the `fromAmino` function, the type identifiers for `MsgUpdateIbcPermAdmin` and `MsgUpdatePermissionedRelayers` should use the prefix `'ibc-perm/'` as the valid identifier.
Learnt from: evilpeach
PR: initia-labs/tx-decoder#28
File: src/metadata-resolver.ts:27-32
Timestamp: 2025-07-03T01:32:16.425Z
Learning: In the tx-decoder project, Zod is used for data validation at the input layer, which means direct property access is safe in functions like `resolveMetadata` since the data structure is already validated. Optional chaining is not needed in such cases.
src/tests/move/nft-burn.test.ts (1)
Learnt from: joon9823
PR: initia-labs/initia.js#86
File: src/client/rest/api/IbcAPI.spec.ts:4-4
Timestamp: 2024-10-18T02:40:07.439Z
Learning: In `src/client/rest/api/IbcAPI.spec.ts`, the REST endpoint `https://rest.devnet.initia.xyz/` is acceptable even if it returns a 501 Not Implemented status code.
src/tests/ibc/send-nft.test.ts (4)
Learnt from: joon9823
PR: initia-labs/initia.js#81
File: src/core/Msg.ts:518-521
Timestamp: 2024-10-08T18:48:55.677Z
Learning: In `src/core/Msg.ts`, within the `fromAmino` function, the type identifiers for `MsgUpdateIbcPermAdmin` and `MsgUpdatePermissionedRelayers` should use the prefix `'ibc-perm/'` as the valid identifier.
Learnt from: joon9823
PR: initia-labs/initia.js#81
File: src/core/Msg.ts:518-521
Timestamp: 2024-10-07T09:09:55.619Z
Learning: In `src/core/Msg.ts`, within the `fromAmino` function, the type identifiers for `MsgUpdateIbcPermAdmin` and `MsgUpdatePermissionedRelayers` should use the prefix `'ibc-perm/'` as the valid identifier.
Learnt from: joon9823
PR: initia-labs/initia.js#86
File: src/client/rest/api/IbcAPI.spec.ts:4-4
Timestamp: 2024-10-18T02:40:07.439Z
Learning: In `src/client/rest/api/IbcAPI.spec.ts`, the REST endpoint `https://rest.devnet.initia.xyz/` is acceptable even if it returns a 501 Not Implemented status code.
Learnt from: evilpeach
PR: initia-labs/tx-decoder#28
File: src/metadata-resolver.ts:27-32
Timestamp: 2025-07-03T01:32:16.425Z
Learning: In the tx-decoder project, Zod is used for data validation at the input layer, which means direct property access is safe in functions like `resolveMetadata` since the data structure is already validated. Optional chaining is not needed in such cases.
src/tests/fixtures/ibc/send-nft.fixture.ts (2)
Learnt from: joon9823
PR: initia-labs/initia.js#86
File: src/client/rest/api/IbcAPI.spec.ts:4-4
Timestamp: 2024-10-18T02:40:07.439Z
Learning: In `src/client/rest/api/IbcAPI.spec.ts`, the REST endpoint `https://rest.devnet.initia.xyz/` is acceptable even if it returns a 501 Not Implemented status code.
Learnt from: joon9823
PR: initia-labs/initia.js#113
File: src/client/rest/RESTClient.ts:178-178
Timestamp: 2025-03-04T07:53:30.367Z
Learning: In the `RESTClient` class of Initia.js, the `gasPrices()` method is designed to return `undefined` when both API calls (opchild and move) fail, which is an intentional design choice.
src/tests/fixtures/move/nft-burn.fixture.ts (2)
Learnt from: joon9823
PR: initia-labs/initia.js#86
File: src/client/rest/api/IbcAPI.spec.ts:4-4
Timestamp: 2024-10-18T02:40:07.439Z
Learning: In `src/client/rest/api/IbcAPI.spec.ts`, the REST endpoint `https://rest.devnet.initia.xyz/` is acceptable even if it returns a 501 Not Implemented status code.
Learnt from: joon9823
PR: initia-labs/initia.js#113
File: src/client/rest/RESTClient.ts:178-178
Timestamp: 2025-03-04T07:53:30.367Z
Learning: In the `RESTClient` class of Initia.js, the `gasPrices()` method is designed to return `undefined` when both API calls (opchild and move) fail, which is an intentional design choice.
src/decoders/ibc/nft.ts (2)
Learnt from: joon9823
PR: initia-labs/initia.js#81
File: src/core/Msg.ts:518-521
Timestamp: 2024-10-08T18:48:55.677Z
Learning: In `src/core/Msg.ts`, within the `fromAmino` function, the type identifiers for `MsgUpdateIbcPermAdmin` and `MsgUpdatePermissionedRelayers` should use the prefix `'ibc-perm/'` as the valid identifier.
Learnt from: joon9823
PR: initia-labs/initia.js#81
File: src/core/Msg.ts:518-521
Timestamp: 2024-10-07T09:09:55.619Z
Learning: In `src/core/Msg.ts`, within the `fromAmino` function, the type identifiers for `MsgUpdateIbcPermAdmin` and `MsgUpdatePermissionedRelayers` should use the prefix `'ibc-perm/'` as the valid identifier.
src/tests/fixtures/move/object-transfer.fixture.ts (1)
Learnt from: joon9823
PR: initia-labs/initia.js#113
File: src/client/rest/RESTClient.ts:178-178
Timestamp: 2025-03-04T07:53:30.367Z
Learning: In the `RESTClient` class of Initia.js, the `gasPrices()` method is designed to return `undefined` when both API calls (opchild and move) fail, which is an intentional design choice.
src/interfaces/decoded-messages.ts (3)
Learnt from: joon9823
PR: initia-labs/initia.js#81
File: src/core/Msg.ts:518-521
Timestamp: 2024-10-08T18:48:55.677Z
Learning: In `src/core/Msg.ts`, within the `fromAmino` function, the type identifiers for `MsgUpdateIbcPermAdmin` and `MsgUpdatePermissionedRelayers` should use the prefix `'ibc-perm/'` as the valid identifier.
Learnt from: joon9823
PR: initia-labs/initia.js#81
File: src/core/Msg.ts:518-521
Timestamp: 2024-10-07T09:09:55.619Z
Learning: In `src/core/Msg.ts`, within the `fromAmino` function, the type identifiers for `MsgUpdateIbcPermAdmin` and `MsgUpdatePermissionedRelayers` should use the prefix `'ibc-perm/'` as the valid identifier.
Learnt from: evilpeach
PR: initia-labs/tx-decoder#28
File: src/metadata-resolver.ts:27-32
Timestamp: 2025-07-03T01:32:16.425Z
Learning: In the tx-decoder project, Zod is used for data validation at the input layer, which means direct property access is safe in functions like `resolveMetadata` since the data structure is already validated. Optional chaining is not needed in such cases.
src/tests/ibc/receive-nft.test.ts (4)
Learnt from: joon9823
PR: initia-labs/initia.js#81
File: src/core/Msg.ts:518-521
Timestamp: 2024-10-08T18:48:55.677Z
Learning: In `src/core/Msg.ts`, within the `fromAmino` function, the type identifiers for `MsgUpdateIbcPermAdmin` and `MsgUpdatePermissionedRelayers` should use the prefix `'ibc-perm/'` as the valid identifier.
Learnt from: joon9823
PR: initia-labs/initia.js#81
File: src/core/Msg.ts:518-521
Timestamp: 2024-10-07T09:09:55.619Z
Learning: In `src/core/Msg.ts`, within the `fromAmino` function, the type identifiers for `MsgUpdateIbcPermAdmin` and `MsgUpdatePermissionedRelayers` should use the prefix `'ibc-perm/'` as the valid identifier.
Learnt from: joon9823
PR: initia-labs/initia.js#86
File: src/client/rest/api/IbcAPI.spec.ts:4-4
Timestamp: 2024-10-18T02:40:07.439Z
Learning: In `src/client/rest/api/IbcAPI.spec.ts`, the REST endpoint `https://rest.devnet.initia.xyz/` is acceptable even if it returns a 501 Not Implemented status code.
Learnt from: ALPAC-4
PR: initia-labs/rapid-relayer#20
File: src/db/controller/client.ts:54-66
Timestamp: 2024-12-17T07:59:34.765Z
Learning: In `src/db/controller/client.ts`, `consensusHeights` must exist and follow the `number-number` format as per the IBC-Go specification. If it doesn't exist or the format is incorrect, the process should throw an error and terminate.
src/tests/fixtures/move/nft-mint.fixture.ts (1)
Learnt from: joon9823
PR: initia-labs/initia.js#86
File: src/client/rest/api/IbcAPI.spec.ts:4-4
Timestamp: 2024-10-18T02:40:07.439Z
Learning: In `src/client/rest/api/IbcAPI.spec.ts`, the REST endpoint `https://rest.devnet.initia.xyz/` is acceptable even if it returns a 501 Not Implemented status code.
src/tests/fixtures/ibc/receive-nft.fixture.ts (4)
Learnt from: joon9823
PR: initia-labs/initia.js#86
File: src/client/rest/api/IbcAPI.spec.ts:4-4
Timestamp: 2024-10-18T02:40:07.439Z
Learning: In `src/client/rest/api/IbcAPI.spec.ts`, the REST endpoint `https://rest.devnet.initia.xyz/` is acceptable even if it returns a 501 Not Implemented status code.
Learnt from: joon9823
PR: initia-labs/initia.js#81
File: src/core/Msg.ts:518-521
Timestamp: 2024-10-08T18:48:55.677Z
Learning: In `src/core/Msg.ts`, within the `fromAmino` function, the type identifiers for `MsgUpdateIbcPermAdmin` and `MsgUpdatePermissionedRelayers` should use the prefix `'ibc-perm/'` as the valid identifier.
Learnt from: joon9823
PR: initia-labs/initia.js#81
File: src/core/Msg.ts:518-521
Timestamp: 2024-10-07T09:09:55.619Z
Learning: In `src/core/Msg.ts`, within the `fromAmino` function, the type identifiers for `MsgUpdateIbcPermAdmin` and `MsgUpdatePermissionedRelayers` should use the prefix `'ibc-perm/'` as the valid identifier.
Learnt from: joon9823
PR: initia-labs/initia.js#113
File: src/client/rest/RESTClient.ts:178-178
Timestamp: 2025-03-04T07:53:30.367Z
Learning: In the `RESTClient` class of Initia.js, the `gasPrices()` method is designed to return `undefined` when both API calls (opchild and move) fail, which is an intentional design choice.
src/decoders/move/nft.ts (2)
Learnt from: joon9823
PR: initia-labs/initia.js#81
File: src/core/Msg.ts:518-521
Timestamp: 2024-10-08T18:48:55.677Z
Learning: In `src/core/Msg.ts`, within the `fromAmino` function, the type identifiers for `MsgUpdateIbcPermAdmin` and `MsgUpdatePermissionedRelayers` should use the prefix `'ibc-perm/'` as the valid identifier.
Learnt from: joon9823
PR: initia-labs/initia.js#81
File: src/core/Msg.ts:518-521
Timestamp: 2024-10-07T09:09:55.619Z
Learning: In `src/core/Msg.ts`, within the `fromAmino` function, the type identifiers for `MsgUpdateIbcPermAdmin` and `MsgUpdatePermissionedRelayers` should use the prefix `'ibc-perm/'` as the valid identifier.
🧬 Code Graph Analysis (5)
src/schema/resources.ts (1)
src/schema/common.ts (1)
zJsonString(20-30)
src/tests/move/nft-burn.test.ts (3)
src/tests/helpers/initialize.ts (1)
initialize(3-8)src/tests/helpers/api.ts (3)
resetMockApi(21-24)mockedAxios(10-10)setupMockApi(12-19)src/tests/fixtures/move/nft-burn.fixture.ts (2)
mockApiResponsesForNftBurn(304-366)mockMsgNftBurn(1-302)
src/interfaces/metadata.ts (1)
src/schema/resources.ts (1)
CollectionResource(65-65)
src/api.ts (1)
src/schema/resources.ts (2)
CollectionResource(65-65)zCollectionResource(54-64)
src/interfaces/decoded-messages.ts (1)
src/schema/resources.ts (1)
CollectionResource(65-65)
🔇 Additional comments (32)
src/tests/fixtures/move/object-transfer.fixture.ts (1)
351-408: LGTM! Comprehensive mock data for collection resources.The mock API response data is well-structured and includes all the necessary Move resources (ObjectCore, Royalty, Collection, FixedSupply, InitiaNftCollection, SimpleNftCollection) with proper JSON data, raw bytes, and struct tags. This effectively supports testing the enhanced collection metadata functionality.
src/interfaces/metadata.ts (2)
1-1: LGTM! Proper import and type usage.The import correctly references the
CollectionResourcetype from the schema module.
5-5: LGTM! Correct type reference for collection data.The
collectionproperty correctly usesCollectionResource["data"]type, which aligns with the Zod schema structure and follows the established pattern in the codebase.src/tests/move/object-transfer.test.ts (1)
63-69: LGTM! Test expectations updated correctly for enhanced collection metadata.The test now expects a detailed
collectionobject with all the necessary fields (creator, description, name, uri) instead of just a URI string. This correctly reflects the enhanced collection metadata functionality.src/schema/resources.ts (1)
54-65: LGTM! Well-defined schema for collection resources.The
zCollectionResourceschema correctly:
- Uses
zJsonString.pipe()to parse JSON strings following the established pattern- Validates all necessary collection fields (creator, description, name, uri)
- Uses the correct type literal
"0x1::collection::Collection"for Move resources- Exports the properly inferred TypeScript type
This provides robust validation for collection metadata throughout the codebase.
src/tests/ibc/send-nft.test.ts (3)
28-35: LGTM! Test expectations updated for enhanced collection metadata.The test correctly expects a detailed
collectionobject with all necessary fields (creator, description, name, uri) instead of just acollectionUristring. This aligns with the enhanced IBC NFT decoding functionality.
74-81: LGTM! Metadata expectations updated consistently.The metadata test expectations correctly include the detailed collection object, maintaining consistency with the decoded message structure.
109-109: LGTM! Property access updated correctly.The property access is correctly updated from
collectionUritocollection.urito match the new nested collection structure.src/tests/move/nft-mint.test.ts (1)
30-36: LGTM: Comprehensive test coverage for collection metadata enhancement.The test correctly validates the new enriched data structure that includes detailed collection metadata (creator, description, name, uri) in both the decoded message and metadata objects. The addition of
tokenUrifield and the structured collection object aligns well with the enhanced NFT decoding functionality.Also applies to: 43-43, 68-74
src/tests/move/nft-burn.test.ts (1)
1-10: LGTM: Proper test setup for asynchronous collection metadata fetching.The test correctly imports and configures mock API responses to support the new collection metadata fetching functionality. The beforeEach hook ensures clean test state, and the expected decoded message structure properly validates the enriched collection data.
Also applies to: 16-18, 21-21, 28-34
src/tests/fixtures/ibc/send-nft.fixture.ts (1)
434-465: LGTM: Comprehensive mock collection resource data.The fixture provides realistic and complete mock data for collection resources, including all required fields (creator, description, name, uri) that align with the
CollectionResourceschema. The mock response structure properly supports testing of the new asynchronous collection metadata fetching functionality.src/metadata-resolver.ts (1)
27-59: LGTM: Robust error handling and metadata construction.The error handling properly distinguishes between missing NFT and collection metadata with specific logging, and the metadata construction correctly uses
toBech32for address conversion while preserving all collection details from the API response.src/tests/fixtures/move/nft-burn.fixture.ts (1)
304-366: LGTM! Comprehensive mock data for collection metadata.The mock API responses provide excellent test coverage for the enhanced NFT burn decoder with detailed collection metadata. The fixture includes all necessary Move resource types and properly structured collection data.
src/decoders/ibc/nft.ts (5)
18-18: Decoder parameter updated correctly.Good change from unused
_apiClientto actively usedapiClientparameter for collection data fetching.
41-50: Proper async collection fetching with error handling.The collection fetching logic is well-implemented with appropriate error handling for missing data. The error message provides clear context about which collection address failed.
55-60: Enhanced collection metadata structure.The new collection object structure provides much richer metadata compared to the previous simple
collectionUristring. The fallback toparsedData.data.classUriis a good design choice.
82-82: Consistent parameter update for receive decoder.The parameter change is consistent with the send decoder implementation.
131-136: Consistent enhanced metadata structure.The receive decoder now provides the same rich collection metadata structure as the send decoder, ensuring consistency across IBC NFT operations.
src/tests/fixtures/move/nft-mint.fixture.ts (1)
329-386: Excellent test fixture for enhanced NFT mint decoder.The mock API responses provide comprehensive collection metadata that aligns perfectly with the enhanced decoding functionality. The data structure is consistent and includes all necessary Move resource types.
src/interfaces/decoded-messages.ts (4)
1-1: Proper import of CollectionResource type.The import statement correctly includes the CollectionResource type needed for the enhanced interface definitions.
155-155: Enhanced NFT mint interface with collection metadata.The addition of
collection: CollectionResource["data"]provides rich collection metadata for mint operations, replacing the previous simpler structure.
186-191: Rich collection metadata for IBC send operations.The replacement of
collectionUriwith a detailed collection object containing creator, description, name, and uri fields significantly enhances the metadata available for IBC NFT send operations.
205-210: Consistent collection metadata for IBC receive operations.The IBC receive interface now matches the send interface structure, ensuring consistency across IBC NFT operations with the same rich collection metadata.
src/tests/fixtures/ibc/receive-nft.fixture.ts (4)
1564-1564: Good fixture organization for different IBC scenarios.The renaming to
mockApiResponsesForIbcReceiveNftSourceTokenclearly indicates this fixture is for source token scenarios, improving test organization.
1615-1672: Comprehensive collection metadata for source tokens.The mock API responses include all necessary Move resource types with detailed collection metadata, supporting thorough testing of the enhanced decoder functionality.
1677-1677: Clear separation for remote token scenarios.The new
mockApiResponsesForIbcReceiveNftRemoteTokenfixture provides distinct test data for remote token scenarios, enhancing test coverage.
1712-1759: Detailed collection data for remote token testing.The mock responses for remote tokens include comprehensive collection metadata with proper structure, enabling thorough testing of the collection data enrichment functionality.
src/decoders/move/nft.ts (3)
17-17: LGTM! Proper parameter usage update.The decoders now correctly use the
apiClientparameter instead of the unused_apiClient, enabling the collection data fetching functionality.Also applies to: 79-79
39-46: Excellent addition of collection data fetching with proper error handling.The asynchronous collection data fetching is well-implemented with appropriate error handling and descriptive error messages that include the collection address for debugging.
Also applies to: 90-97
53-58: Well-structured collection data enrichment.The nested
collectionobject with detailed metadata (creator,description,name,uri) provides comprehensive information and follows a consistent structure across both decoders.Also applies to: 102-107
src/tests/ibc/receive-nft.test.ts (2)
23-90: Excellent test restructuring with comprehensive validation.The separation of source and remote token scenarios into dedicated test blocks improves clarity and maintainability. The comprehensive assertions validate the new collection data structure thoroughly.
92-181: Well-organized remote token test with detailed assertions.The remote token test properly validates the enriched collection metadata, including the handling of null URI values being transformed to empty strings.
2 participants
Summary by CodeRabbit
New Features
Bug Fixes
Tests
Chores