Drift
Both getExecutionPriceDetailed (TS) and get_execution_price_detailed (Python) were rewritten in the same PR (#1308) to compute locally, adding a new defensive check for non-positive amount — but using different, non-equivalent exception types. Because Python's non-detailed get_execution_price delegates to get_execution_price_detailed, it inherits this validation and now raises for amount <= 0. TypeScript's non-detailed getExecutionPrice is an independent implementation with no such guard, so it silently returns a nonsensical numeric result instead of erroring.
TypeScript SDK
sdks/typescript/pmxt/client.ts:2808-2809 (in getExecutionPriceDetailed):
if (amount <= 0) {
throw new Error('Amount must be greater than 0');
}
getExecutionPrice (sdks/typescript/pmxt/client.ts:2781-2793) has no equivalent guard — verified empirically: getExecutionPrice(orderBook, 'buy', 0) returns NaN, and getExecutionPrice(orderBook, 'buy', -5) returns a bogus price (e.g. 0.5) computed from the first book level, with no exception thrown.
Python SDK
sdks/python/pmxt/client.py:3429-3430 (in get_execution_price_detailed):
if amount <= 0:
raise ValueError("Amount must be greater than 0")
get_execution_price (sdks/python/pmxt/client.py:3392-3410) delegates to get_execution_price_detailed, so it inherits this ValueError for the same inputs.
Expected
Both SDKs' non-detailed getExecutionPrice/get_execution_price methods should behave identically for amount <= 0 — either both should raise (with the same exception type, ideally a typed PmxtError/InvalidOrder rather than a bare Error/ValueError), or both should return a defined sentinel value without throwing.
Impact
Identical calls with identical (invalid) inputs produce a raised exception in Python and a silently wrong numeric result (NaN or a bogus price) in TypeScript — a real, user-facing functional difference that could let a caller compute and act on a nonsensical execution price in TypeScript without any error signal. This is not covered by existing issue #930 (scoped to create_order/build_order) or #931 (about getExecutionPriceDetailed's auth headers, now moot since the method no longer calls the server).
Found by automated SDK cross-language drift audit
Drift
Both
getExecutionPriceDetailed(TS) andget_execution_price_detailed(Python) were rewritten in the same PR (#1308) to compute locally, adding a new defensive check for non-positiveamount— but using different, non-equivalent exception types. Because Python's non-detailedget_execution_pricedelegates toget_execution_price_detailed, it inherits this validation and now raises foramount <= 0. TypeScript's non-detailedgetExecutionPriceis an independent implementation with no such guard, so it silently returns a nonsensical numeric result instead of erroring.TypeScript SDK
sdks/typescript/pmxt/client.ts:2808-2809(ingetExecutionPriceDetailed):getExecutionPrice(sdks/typescript/pmxt/client.ts:2781-2793) has no equivalent guard — verified empirically:getExecutionPrice(orderBook, 'buy', 0)returnsNaN, andgetExecutionPrice(orderBook, 'buy', -5)returns a bogus price (e.g.0.5) computed from the first book level, with no exception thrown.Python SDK
sdks/python/pmxt/client.py:3429-3430(inget_execution_price_detailed):get_execution_price(sdks/python/pmxt/client.py:3392-3410) delegates toget_execution_price_detailed, so it inherits thisValueErrorfor the same inputs.Expected
Both SDKs' non-detailed
getExecutionPrice/get_execution_pricemethods should behave identically foramount <= 0— either both should raise (with the same exception type, ideally a typedPmxtError/InvalidOrderrather than a bareError/ValueError), or both should return a defined sentinel value without throwing.Impact
Identical calls with identical (invalid) inputs produce a raised exception in Python and a silently wrong numeric result (
NaNor a bogus price) in TypeScript — a real, user-facing functional difference that could let a caller compute and act on a nonsensical execution price in TypeScript without any error signal. This is not covered by existing issue #930 (scoped tocreate_order/build_order) or #931 (aboutgetExecutionPriceDetailed's auth headers, now moot since the method no longer calls the server).Found by automated SDK cross-language drift audit