Skip to content

fix: tolerate empty-string decimal fields in trade responses - #96

Open
Envy-Life wants to merge 1 commit into
Polymarket:mainfrom
Envy-Life:fix/trade-decimal-empty-string
Open

fix: tolerate empty-string decimal fields in trade responses#96
Envy-Life wants to merge 1 commit into
Polymarket:mainfrom
Envy-Life:fix/trade-decimal-empty-string

Conversation

@Envy-Life

@Envy-Life Envy-Life commented Jul 21, 2026

Copy link
Copy Markdown

Problem

GET /data/trades responses can carry "" in Decimal-typed fields, which makes the whole trades fetch fail to deserialize:

invalid value: string "", expected a Decimal type representing a fixed-point number

We hit this in production while paging a user's trades through Client::trades — one trade with an empty decimal field poisons the entire page.

This is the same venue behavior already handled for TradeResponse.transaction_hash (empty until the async execution pipeline broadcasts the trade's transaction, tolerated via empty_string_as_zero_hash) and for PostOrderResponse.making_amount/taking_amount (empty_string_as_zero) — but the Decimal fields of TradeResponse and its MakerOrders still hard-fail on "".

Fix

Apply the existing empty_string_as_zero deserializer to:

  • TradeResponse: size, fee_rate_bps, price
  • MakerOrder: matched_amount, price, fee_rate_bps

No API change — only widens accepted wire input, mirroring the established pattern.

Testing

Added trades_should_tolerate_empty_decimal_fields (mirrors trades_should_tolerate_empty_transaction_hash), asserting all six fields deserialize to Decimal::ZERO when the venue sends "".

cargo test --features clob --test clob trades_should_
running 4 tests ... 4 passed

(Note: couldn't apply the wip label from a fork — maintainers, feel free to add if desired.)


Note

Low Risk
Deserialization-only widening with an established helper; no API or trading logic changes, though callers may see zero instead of a hard error for malformed venue data.

Overview
Trade list deserialization no longer fails when the venue sends "" for numeric trade fields on GET /data/trades.

TradeResponse (size, fee_rate_bps, price) and nested MakerOrder (matched_amount, price, fee_rate_bps) now use the existing empty_string_as_zero deserializer, matching PostOrderResponse and the empty transaction_hash handling. Empty strings map to Decimal::ZERO; valid numeric strings behave as before.

A CLOB integration test asserts a full trades page still parses when those six fields are empty on the trade and its maker order.

Reviewed by Cursor Bugbot for commit 9e59efc. Bugbot is set up for automated code reviews on this repo. Configure here.

The CLOB can return "" for size, fee_rate_bps, and price on trades (and
their maker orders) before settlement details are populated, which made
TradeResponse deserialization fail with:

  invalid value: string "", expected a Decimal type representing a
  fixed-point number

Apply the existing empty_string_as_zero deserializer (already used for
PostOrderResponse amounts and TradeResponse.transaction_hash) to the
Decimal fields of TradeResponse and MakerOrder.
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