Skip to content

refactor(wallets): extract shared quorum member matching (M4-4 part 1/4) - #1997

Open
panosinthezone wants to merge 1 commit into
panos/wal-11291-m4-3-sdk-teach-the-approval-loop-the-nested-quorumapprovalsfrom
panos/wal-11292-m4-4a-quorum-member-matching-util
Open

refactor(wallets): extract shared quorum member matching (M4-4 part 1/4)#1997
panosinthezone wants to merge 1 commit into
panos/wal-11291-m4-3-sdk-teach-the-approval-loop-the-nested-quorumapprovalsfrom
panos/wal-11292-m4-4a-quorum-member-matching-util

Conversation

@panosinthezone

Copy link
Copy Markdown
Contributor

Linear: WAL-11292 · EDD §6.5 · Stacked on M4-3 (#1993) · Part 1/4 of the M4-4 stack (split from #1996)

Summary

Pure refactor + new shared utility, no behavior change. Extracts the quorum-member matching that WalletFactory.isMatchingQuorumMember did inline into src/utils/quorum-members.ts, so the useSigner selection flows (part 4) and SignerManager (part 2) can reuse the exact same per-type semantics:

  • matchesQuorumMember(candidate, member, serverCandidateAddresses) — per-type matching (email normalized, phone exact, external-wallet by address, passkey by id → name → permissive, server by derived addresses incl. legacy). Server derivation is injected so each caller plugs its own provider.
  • getQuorumMemberLocator(member) — API locator when present, derived fallback otherwise.
  • ResolvedQuorumMember type: API identity fields + index signature admitting runtime fields (server secret, external-wallet onSign, passkey callbacks) that later parts graft on.

The factory now delegates to the shared matcher and — the one incidental fix — wipes the derived key bytes after the address comparison (secureWipe), which the inline version omitted.

Testing

  • New quorum-members.test.ts matcher table (all member types, normalization, permissive passkey, server candidate injection).
  • Full packages/wallets suite: 708 passed.

🤖 Generated with Claude Code

…uorum-members

Introduces getQuorumMemberLocator/matchesQuorumMember and the ResolvedQuorumMember
type, and rewires WalletFactory.isMatchingQuorumMember onto the shared helper
(now also wiping derived key bytes after address comparison). No behavior change.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@changeset-bot

changeset-bot Bot commented Jul 29, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 67cd5fc

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

@greptile-apps

greptile-apps Bot commented Jul 29, 2026

Copy link
Copy Markdown
Contributor
Prompt To Fix All With AI
### Issue 1
packages/wallets/src/wallets/wallet-factory.ts:517-534
**Naming inversion at the call site**

The local parameter `candidate` in `isMatchingQuorumMember` is the API-returned member, but it maps to the `member` parameter of `matchesQuorumMember`. Conversely, `method` (the user-supplied config) maps to the function's `candidate` parameter. Because both types resolve to `{ type: string } & Record<string, unknown>`, TypeScript cannot catch a future accidental swap, and the asymmetry makes the relationship between the two functions non-obvious. Adding a brief inline note or renaming the local `candidate` parameter (e.g. `quorumMember`) to reflect its role as the API-returned member would make the call site self-documenting.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Reviews (1): Last reviewed commit: "refactor(wallets): extract shared quorum..." | Re-trigger Greptile

Comment on lines +130 to +138
export type ResolvedQuorumMember = Record<string, unknown> & {
type: string;
locator?: string;
address?: string;
email?: string;
phone?: string;
id?: string;
name?: string;
};

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be a discriminated union?

Comment on lines +12 to +14
if (typeof member.locator === "string") {
return member.locator;
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How can it not have a locator?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants