Skip to content

fix(express): support Go Account walletId withdrawals - #9751

Draft
bitgo-ai-agent-dev[bot] wants to merge 7 commits into
masterfrom
CAAS-2627-allow-go-account-withdrawals-walletid
Draft

bitgo-ai-agent-dev[bot] wants to merge 7 commits into
masterfrom
CAAS-2627-allow-go-account-withdrawals-walletid

Conversation

@bitgo-ai-agent-dev

Copy link
Copy Markdown
Contributor

What

  • Allow the sendcoins endpoint to accept a Go Account walletId instead of address.
  • Preserve walletId-only destinations through Wallet.send() into the sendMany recipient payload.
  • Add Express route and SDK regression coverage.

Why

The documented Go Account withdrawal flow uses walletId for transfers to another Go Account. Express currently requires address, so valid Testnet withdrawals fail before the request reaches the backend.

Test plan

  • yarn --cwd modules/sdk-core build
  • yarn --cwd modules/express build
  • Targeted sendcoins, validation, and SDK regression tests pass (51 tests).
  • yarn lint-changed passes.
  • Full Express unit test run exercised 1,890 passing tests; 12 unrelated existing failures remain from missing test configuration and baseline mocks.

Ticket: CAAS-2627

Allow sendcoins requests to use a Go Account walletId in place of an address, and pass that destination through the SDK as a recipient. This fixes the documented Go Account withdrawal flow, which was rejected by Express validation before reaching the backend.\n\nTicket: CAAS-2627

Session-Id: f7d1c24e-f50f-4e09-868c-b37a42b4a817
Task-Id: 8c59a039-fe33-48b3-8450-dd2d6ce009bc
Share the walletId-capable recipient shape with prebuild options so the SDK compiles across dependent packages, and narrow the validation path before checking recipients. This preserves the Go Account destination through all send flows without weakening address validation for malformed requests.\n\nTicket: CAAS-2627

Session-Id: f7d1c24e-f50f-4e09-868c-b37a42b4a817
Task-Id: 8c59a039-fe33-48b3-8450-dd2d6ce009bc
Keep walletId support internal to the send-to-sendMany conversion while retaining the existing prebuild recipient contract. This avoids widening address-only APIs and keeps all dependent packages type-safe.\n\nTicket: CAAS-2627

Session-Id: f7d1c24e-f50f-4e09-868c-b37a42b4a817
Task-Id: 8c59a039-fe33-48b3-8450-dd2d6ce009bc
Keep the converted recipient list non-optional after validating the send destination. This resolves the remaining SDK core type errors while preserving walletId-only Go Account withdrawals.\n\nTicket: CAAS-2627

Session-Id: f7d1c24e-f50f-4e09-868c-b37a42b4a817
Task-Id: 8c59a039-fe33-48b3-8450-dd2d6ce009bc
Model sendcoins destinations as an address-or-walletId union while retaining the existing amount and option validation. This lets Go Account requests omit address without allowing requests with no destination, preserving readable validation errors for malformed withdrawals.\n\nTicket: CAAS-2627

Session-Id: f7d1c24e-f50f-4e09-868c-b37a42b4a817
Task-Id: 8c59a039-fe33-48b3-8450-dd2d6ce009bc
Keep the sendcoins request body as the existing property map while making address optional and adding walletId. The typed route infrastructure requires property maps, so destination presence remains enforced by the handler without breaking generated route types.\n\nTicket: CAAS-2627

Session-Id: f7d1c24e-f50f-4e09-868c-b37a42b4a817
Task-Id: 8c59a039-fe33-48b3-8450-dd2d6ce009bc
Keep the existing property-map codec test pattern after retaining the typed route's compatible request shape. The regression test still covers walletId-only destinations without introducing unrelated codec type errors.\n\nTicket: CAAS-2627

Session-Id: f7d1c24e-f50f-4e09-868c-b37a42b4a817
Task-Id: 8c59a039-fe33-48b3-8450-dd2d6ce009bc
@bitgo-ai-agent-dev
bitgo-ai-agent-dev Bot force-pushed the CAAS-2627-allow-go-account-withdrawals-walletid branch from b7aebbc to e8c5929 Compare September 16, 2026 18:29
@github-actions

github-actions Bot commented Sep 16, 2026

Copy link
Copy Markdown
Contributor

⚠️ Unit tests are failing on Node 26.x (Current release line, non-blocking). This is not an LTS version yet, so it does not block merge, but it signals an incompatibility to fix before Node 26.x becomes LTS.

View run

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.

1 participant