Monaco Protocol SDK v1.0.64
This release rolls up the consumer-facing changes since v1.0.62. Order history —sdk.trading.getPaginatedOrders — now always returns an item count in both pagination modes, bounded by a server ceiling so a large history never drives an unbounded count, and the response carries a new totalCapped flag that tells you when that count is a lower bound. The response schema is additive — totalCapped is new and nothing is removed — but the count values change in two cases: cursor (pageToken) mode now populates total and totalPages — a count over full history, hot and archived rows merged — where it previously returned 0, and a page-number caller with more than the ceiling of matching orders in its recent-history window now reads the capped ceiling instead of the exact count of that window. Check totalCapped to tell an exact count from a saturated one. v1.0.63 shipped no consumer-facing changes.
Added
Order history returns a bounded item count in both pagination modes
sdk.trading.getPaginatedOrders (GET /api/v1/orders, authenticated; gRPC OrdersService.ListOrders) now populates total and totalPages in both pagination modes — legacy page-number and cursor (pageToken) alike — where cursor mode previously returned 0 for both and offered no exact total. The count is bounded by a server ceiling of 10,000: it stays exact up to that many matching orders and saturates there, so a wallet with a very large order history no longer triggers an unbounded COUNT over the orders table on every page render. pageSize up to 1000 in cursor mode is unchanged.
GetPaginatedOrdersResponse gains totalCapped (boolean): true when more than the ceiling matched, so total and totalPages are a lower bound — at least that many orders exist — rather than an exact figure; false when total is exact, including exactly the ceiling, which is still reported exactly. total and totalPages are no longer deprecated now that both modes populate them; only page stays deprecated and still comes back as 0 in cursor mode.
Neither pagination loop breaks: cursor walks still terminate on an empty nextPageToken, and page-number loops that stop at page >= totalPages keep terminating. The count values are not identical to before, though: in cursor mode total and totalPages (a count over full history, hot and archived merged) were 0 and are now populated, and a page-number caller with more than 10,000 orders in its recent-history window now reads the capped ceiling rather than the exact count of that window (a page-number caller under the ceiling still reads the same exact total). Code that reads total as an exact figure should treat a capped value as “at least this many” and check totalCapped to tell an exact count from a saturated one.
See Order history and the API reference.
Upgrade
total/totalPages where it returned 0, and a page-number count above 10,000 saturates at the ceiling — so if you read total as an exact count, treat a capped value as “at least this many” and read the new totalCapped flag to tell an exact count from a saturated one.