At v2-dev commit 8c899cc53bdb17372782ac538a8d77e166be912a, the default receipt projection appears to omit decoded method/argument Maps, rather than only removing raw presentation metadata.
Source path:
src/abi/calldata/decoder.ts: TYPE_MAP returns a JavaScript Map.src/transactions/decoders.ts: decodeInputData assigns the decoded value to txDataDecoded.callData or constructorArgs.- The simplifier uses
Object.entries; a Map becomes an empty object and is omitted by the parent filter.
waitForTransactionReceipt defaults fullTransaction to false and applies that simplifier.
A minimal shape-level observation using simplifyTransactionReceipt:
const tx = {
txDataDecoded: {
callData: new Map<string, unknown>([['', 'inspect_delivery'], ['args', ['synthetic-reference']]]),
leaderOnly: false,
type: 'call',
},
};
// Input callData contains the method and arguments.
// The simplified result is:
// { txDataDecoded: { leaderOnly: false, type: 'call' } }This also occurs for a Map-shaped constructorArgs. Should these decoded fields remain available in the default receipt, or should their omission be explicitly documented? A focused regression fixture at this boundary would help callers inspecting which method/conditions a receipt corresponds to. This is distinct from the existing readContract JSON-safe conversion in #107 and the calldata-string formatting work in #210.
Validation: source inspection plus a dependency-free extraction of the pure simplifier; 11 synthetic observation/control tests passed and were independently rerun. The actual ABI decoder, SDK client, RPC and full upstream suite were not executed. This is pinned-development-source evidence, not a published-release or production-incident claim.
The raw transaction data is not destroyed, and fullTransaction: true bypasses this simplifier. Intentional metadata removal introduced in #101 is not itself a bug; this question concerns the decoded Map fields specifically.
At
v2-devcommit8c899cc53bdb17372782ac538a8d77e166be912a, the default receipt projection appears to omit decoded method/argument Maps, rather than only removing raw presentation metadata.Source path:
src/abi/calldata/decoder.ts:TYPE_MAPreturns a JavaScriptMap.src/transactions/decoders.ts:decodeInputDataassigns the decoded value totxDataDecoded.callDataorconstructorArgs.Object.entries; a Map becomes an empty object and is omitted by the parent filter.waitForTransactionReceiptdefaultsfullTransactionto false and applies that simplifier.A minimal shape-level observation using
simplifyTransactionReceipt:This also occurs for a Map-shaped
constructorArgs. Should these decoded fields remain available in the default receipt, or should their omission be explicitly documented? A focused regression fixture at this boundary would help callers inspecting which method/conditions a receipt corresponds to. This is distinct from the existingreadContractJSON-safe conversion in #107 and the calldata-string formatting work in #210.Validation: source inspection plus a dependency-free extraction of the pure simplifier; 11 synthetic observation/control tests passed and were independently rerun. The actual ABI decoder, SDK client, RPC and full upstream suite were not executed. This is pinned-development-source evidence, not a published-release or production-incident claim.
The raw transaction data is not destroyed, and
fullTransaction: truebypasses this simplifier. Intentional metadata removal introduced in #101 is not itself a bug; this question concerns the decoded Map fields specifically.