[GH-ISSUE #173] None is rejected for Instrument Type fields, causing incorrect defaults (e.g., 0) and wrong pricing #86

New issue

Open

opened 2026-03-03 11:58:47 +03:00 by kerem · 0 comments

kerem commented

2026-03-03 11:58:47 +03:00

Owner

Originally created by @sergeiosipov on GitHub (Feb 9, 2026).
Original GitHub issue: https://github.com/finmars-platform/finmars-core/issues/173

Originally assigned to: @HenkKalkwater on GitHub.

Problem

Some Instrument Type fields do not accept None as a valid value. During Instrument creation, this causes None to be replaced with a default numeric value (commonly 0).

Why this is an issue

0 is treated as a meaningful value, not as “unset”. As a result, downstream pricing and recalculation logic may not trigger, leading to incorrect persisted values.

Example

Create a Bond instrument with an accrual schedule
A field that should be None (meaning “derive from schedule”) is set to 0
During pricing:
- The engine sees a numeric value (0 or any number)
- Recalculation is skipped
The system writes 0 instead of the correct calculated value

Expected behavior

Instrument Type fields that represent “unset / derive / calculate” must allow None
On creation, these fields should remain None unless explicitly provided
Pricing logic should treat:
- None → value must be calculated
- numeric value → explicit override

Actual behavior

Validation rejects None (“None is not a valid value for Instrument Types”)
None is coerced into 0 (or another numeric default)
Pricing logic does not recalculate and persists incorrect values

Impact

Incorrect pricing results (e.g. bonds with accrual schedules)
Silent data corruption risk: stored values look valid but are wrong

Suggested fix

Allow None for affected Instrument Type fields at validation/schema level
Ensure None is preserved through serialization/deserialization (no coercion to 0)
(Optional safety) If accrual schedule exists and value was not explicitly set, force recalculation during pricing

Originally created by @sergeiosipov on GitHub (Feb 9, 2026). Original GitHub issue: https://github.com/finmars-platform/finmars-core/issues/173 Originally assigned to: @HenkKalkwater on GitHub. ### Problem Some Instrument Type fields do **not accept `None`** as a valid value. During Instrument creation, this causes `None` to be replaced with a default numeric value (commonly `0`). ### Why this is an issue `0` is treated as a meaningful value, not as “unset”. As a result, downstream pricing and recalculation logic may **not trigger**, leading to incorrect persisted values. ### Example 1. Create a **Bond** instrument with an **accrual schedule** 2. A field that should be `None` (meaning “derive from schedule”) is set to `0` 3. During pricing: - The engine sees a numeric value (`0` or any number) - Recalculation is skipped 4. The system writes `0` instead of the correct calculated value ### Expected behavior - Instrument Type fields that represent “unset / derive / calculate” **must allow `None`** - On creation, these fields should remain `None` unless explicitly provided - Pricing logic should treat: - `None` → value must be calculated - numeric value → explicit override ### Actual behavior - Validation rejects `None` (“None is not a valid value for Instrument Types”) - `None` is coerced into `0` (or another numeric default) - Pricing logic does not recalculate and persists incorrect values ### Impact - Incorrect pricing results (e.g. bonds with accrual schedules) - Silent data corruption risk: stored values look valid but are wrong ### Suggested fix - Allow `None` for affected Instrument Type fields at validation/schema level - Ensure `None` is preserved through serialization/deserialization (no coercion to `0`) - (Optional safety) If accrual schedule exists and value was not explicitly set, force recalculation during pricing