Fix order deserialization overflow for values at the edge of the decimal range

[Martin-Molinero]

Description

OrderJsonConverter threw a System.OverflowException ("Value was either too large or too small for a Decimal") when deserializing orders whose quantity or prices sit at the edge of the decimal range.

Quantities/prices out of the decimal range are clamped to decimal.MaxValue/decimal.MinValue at order creation — e.g. the QCAlgorithm double-quantity order methods go through Extensions.SafeDecimalCast, so a runaway double quantity in user code (Python floats bind to these overloads) produces an order with Quantity = decimal.MaxValue. That order serializes fine, but on deserialization JObject parses the number back as a double that rounds past the decimal range (decimal.MaxValue is 2⁹⁶ − 1; the nearest double is exactly 2⁹⁶), so Value<decimal>() overflowed and the stored result file could never be read back.

The fix reads decimal fields through a helper that applies the same SafeDecimalCast clamping used at order creation when the token holds a double, mirroring what DecimalJsonConverter already does. Applied to Quantity, Price, OrderSubmissionData prices, stop/limit/trigger prices, trailing amount and GroupOrderManager quantity/limit price.

Related Issue

N/A — hit in production reading stored backtest results.

Motivation and Context

Stored backtest/live results containing such an order could never be deserialized again, permanently breaking result APIs for that backtest.

Requires Documentation Change

No.

How Has This Been Tested?

New unit tests round-trip orders with decimal.MaxValue/MinValue quantity, order-type prices and order submission prices, plus direct deserialization of JSON with out-of-range literals (79228162514264337593543950335.0, 7.9228162514264338E+28, 1E+300) for quantity, price and group order manager fields. All 7 new test cases fail without the fix; full OrderJsonConverterTests fixture passes with it (56/56).

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance. Please add associated performance test and results)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>

🤖 Generated with Claude Code