fix(sdk-core): read defi vault operationId from coinSpecific#9067
Merged
kamleshmugdiya merged 1 commit intoJun 19, 2026
Merged
Conversation
extractOperationId() read txRequest.intent.operationId, but the WP writes the minted operationId into the built transaction's coinSpecific. Read it from transactions[0].unsignedTx.coinSpecific (full apiVersion), falling back to unsignedTxs[0].coinSpecific (lite) and intent.operationId (forward-compat). Fix the stale unit-test mock that put operationId on the intent and masked the bug, and add regression tests for the lite, intent-fallback, and not-found paths. Ticket: CGD-1829 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
hitansh-madan
approved these changes
Jun 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
DefiVault.depositToVault()threwError: operationId not found in approve txRequest responseon every deposit. The approvesendManysucceeded and the WP minted an operationId, but the SDK couldn't locate it and aborted before issuing the depositsendMany.Root cause: a contract mismatch on where
operationIdlives in the approve txRequest response.extractOperationId()readtxRequest.intent.operationId.coinSpecific(next toassignedNonce), which for afulltxRequest surfaces attxRequest.transactions[0].unsignedTx.coinSpecific.operationId. Theintentblock never carries it.Both the SDK comment and the WP docstring claimed "operationId on the intent," and the SDK unit test mocked the response that way — so the bug shipped with green tests on both sides.
Changes
extractOperationId()now readstransactions[0].unsignedTx.coinSpecific.operationId(full apiVersion), falling back tounsignedTxs[0].coinSpecific.operationId(lite) and finallyintent.operationId(forward-compat, in case WP later also populates the intent).defiVault.ts.operationIdon theintentand masked the regression — the approve mocks now use the realcoinSpecificshape.Test plan
mocha test/unit/bitgo/defi/defiVault.ts— 17 passing, 1 pending (CGD-1709 placeholder)eslint— 0 errorsprettier --check— cleanTicket: CGD-1829