Resolve nested seed paths in v01 PDA extraction by ioxde · Pull Request #990 · codama-idl/codama

ioxde · 2026-04-09T02:45:39Z

This is a direct follow-up to #984 which left the nested path handling as a TODO.

PDA seeds with nested paths like mint.authority or args.owner were skipped. This PR resolves them by looking up the field type from IDL type definitions.

{ kind: 'account', path: 'mint.authority' } + a Mint type def with authority: pubkey -> variablePdaSeedNode('mintAuthority', publicKeyTypeNode())

{ kind: 'arg', path: 'args.owner' } where args is a struct with owner: pubkey -> variablePdaSeedNode('owner', publicKeyTypeNode())

Program seeds with nested paths still skip (with a warning). pdaSeedNodeFromAnchorV01 can now return undefined.

changeset-bot · 2026-04-09T02:45:45Z

🦋 Changeset detected

Latest commit: 48b8986

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@codama/nodes-from-anchor	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

lorisleiva · 2026-04-13T13:16:47Z

@trevor-cortex

trevor-cortex

Summary

This PR resolves nested seed paths (e.g. mint.authority, args.owner) in v01 PDA extraction, which were previously left as a TODO and silently skipped. It introduces a resolveNestedFieldType helper that walks struct fields (inline or via IDL type definitions) to determine the leaf type. The function pdaSeedNodeFromAnchorV01 can now return undefined when resolution fails, and callers handle this gracefully by skipping the PDA default value.

Additionally, the PR adds self-referential seed detection — if a seed references the account being derived, the PDA default is skipped with a warning.

Key things to watch

Breaking return type change: pdaSeedNodeFromAnchorV01 now returns | undefined. This is a well-handled breaking change internally — all call sites check for undefined — but any external consumers of this export would need updating.
Self-referential detection: The new self-referential check (lines 131–138 in InstructionAccountNode.ts) correctly catches cases like vault referencing itself, and nested paths like guard.mint where the account name matches the seed's account reference. The test for my_guard with path: 'my_guard.mint' is a good edge case.
Nested program paths: Program seeds with nested paths are still explicitly skipped with a warning — this is a reasonable incremental choice since program seeds with nested paths are rare.

Notes for subsequent reviewers

The resolveNestedFieldType helper only handles structTypeNode and definedTypeLinkNode. Other wrappers (e.g. optionTypeNode) would fall through and return undefined. This seems fine for now — real-world IDL seeds shouldn't reference optional fields — but worth keeping in mind.
The InstructionNode.test.ts change for the distribution account is interesting: it confirms the self-referential detection works at the integration level (the account distribution has a seed path: 'distribution.group_mint' referencing itself, so the PDA default is correctly omitted).
Test coverage is thorough: nested account paths, nested arg paths, unresolvable types, self-referential accounts, prefixed nested groups, and program seed edge cases are all covered.

lorisleiva · 2026-04-13T13:44:03Z

-        // [
-        //     accountNode({
-        //         data: sizePrefixTypeNode(
-        //             structTypeNode([structFieldTypeNode({ name: 'authority', type: publicKeyTypeNode() })]),
-        //             numberTypeNode('u32'),
-        //         ),
-        //         name: 'mint',
-        //     }),
-        // ],


The idea was that these would be uncommented when nested arguments/accounts are supported. Is the idea that the new tests are taking care of that deleted code now?

The commented code assumed account data would be passed directly via accountNode, but nested types are now resolved through idlTypes instead.

lorisleiva · 2026-04-13T13:44:26Z

-        // [
-        //     accountNode({
-        //         data: sizePrefixTypeNode(
-        //             structTypeNode([structFieldTypeNode({ name: 'authority', type: publicKeyTypeNode() })]),
-        //             numberTypeNode('u32'),
-        //         ),
-        //         name: 'mint',
-        //     }),
-        // ],


Same as above

lorisleiva · 2026-04-13T13:51:47Z

+                if (!resolved) {
+                    logWarn(`Could not resolve nested account path "${seed.path}" for PDA seed.`);
+                    return undefined;
+                }


I wonder if here we should just throw? Before we were silently ignoring nested paths because that was a valid scenario we were not able to support. Now that we are, if the nested seed don't resolve properly than it is a malformation on the IDL itself right?

Honestly not sure. I know Anchor PDAs aren't perfect. I think the best path would be to throw by default (with a detailed message pointing to docs/what to fix) but allowing a user to override per error. I am not sure that whole change fits in this PR though. Seems more like a project-level standard / convention?

I personally do like the fail-first override behavior because it forces the user to understand their decisions. Console warnings don't always tell the real severity of the issue / easy to accidentally ignore.

I'll wait for more direction to make changes here.

lorisleiva · 2026-04-13T14:00:28Z

 }
+
+function resolveNestedFieldType(
+    rootType: TypeNode,


I wouldn't call that rootType since there is a RootNode which makes this confusing.

parentType okay?

lorisleiva · 2026-04-13T14:07:58Z

-                    // TODO: Handle seeds with nested paths. (Needs a path in the IDL but should we?)
-                    // defaultValue: pdaValueNode(
-                    //     pdaNode({
-                    //         name: 'distribution',
-                    //         seeds: [
-                    //             constantPdaSeedNodeFromBytes('base58', 'F9bS'),
-                    //             variablePdaSeedNode('distributionGroupMint', publicKeyTypeNode()),
-                    //         ],
-                    //     }),
-                    //     [pdaSeedValueNode("distributionGroupMint", accountValueNode('distribution', 'group_mint'))],
-                    // ),


Same feedback about using idlTypes as above.

lorisleiva · 2026-04-13T14:08:32Z

-    expect(nodes.definition).toEqual(constantPdaSeedNodeFromBytes('base58', 'HeLLo'));
-    expect(nodes.value).toBeUndefined();
+    expect(nodes!.definition).toEqual(constantPdaSeedNodeFromBytes('base58', 'HeLLo'));
+    expect(nodes!.value).toBeUndefined();


If we throw instead of returning undefined, we remove the need for these casts.

I switched all tests to ?.. Unsure about the throw. See above comment about throw vs log.

* found while rebasing onto main

ioxde · 2026-04-15T06:06:51Z

I think I addressed all comments outside of the logWarn vs throw question. Let me know if you have any other questions / concerns.

ioxde force-pushed the nested-pda-seeds branch 2 times, most recently from 4902b1e to 60bfce9 Compare April 12, 2026 23:31

trevor-cortex approved these changes Apr 13, 2026

View reviewed changes

Comment thread packages/nodes-from-anchor/src/v01/PdaSeedNode.ts

Comment thread packages/nodes-from-anchor/src/v01/InstructionAccountNode.ts Outdated

lorisleiva requested changes Apr 13, 2026

View reviewed changes

ioxde added 3 commits April 14, 2026 15:49

Local test fixes

ad3e2c1

Resolve nested seed paths in v01 PDA extraction

7488ec9

Fix dynamic-client tests

09b1602

ioxde force-pushed the nested-pda-seeds branch from 60bfce9 to 2702c2c Compare April 14, 2026 23:58

Fix duplicate seed names for nested arg PDA seeds

a37264c

* found while rebasing onto main

ioxde force-pushed the nested-pda-seeds branch from 2702c2c to a37264c Compare April 15, 2026 00:04

ioxde added 3 commits April 14, 2026 20:11

Resolve nested program seed paths in PDA extraction

10ab1a8

Handle tupleTypeNode in nested PDA seed path resolution

b0c4d41

Address PR feedback

48b8986

Conversation

ioxde commented Apr 9, 2026

Uh oh!

changeset-bot bot commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦋 Changeset detected

Uh oh!

lorisleiva commented Apr 13, 2026

Uh oh!

trevor-cortex left a comment

Choose a reason for hiding this comment

Summary

Key things to watch

Notes for subsequent reviewers

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ioxde Apr 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ioxde commented Apr 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

changeset-bot bot commented Apr 9, 2026 •

edited

Loading

ioxde Apr 15, 2026 •

edited

Loading