nautechsystems/nautilus_trader · error · anyhow::Error
Failed to parse acc_fill_sz='{acc_fill_sz}': {e}
Error message
Failed to parse acc_fill_sz='{acc_fill_sz}': {e} What it means
When fillSz is absent, the adapter derives the incremental fill from the cumulative accFillSz. This error is thrown when parse_quantity fails on acc_fill_sz, meaning the cumulative filled total cannot be represented at the instrument's size precision and the incremental fill cannot be computed.
Source
Thrown at crates/adapters/okx/src/websocket/parse.rs:2112
anyhow::anyhow!(
"Failed to parse price (fill_px='{}', avg_px='{}', px='{}'): {}",
msg.fill_px,
msg.avg_px,
msg.px,
e
)
})?;
// OKX provides fillSz (incremental fill) or accFillSz (cumulative total)
// If fillSz is provided, use it directly as the incremental fill quantity
let last_qty = if !msg.fill_sz.is_empty() && msg.fill_sz != "0" {
parse_quantity(&msg.fill_sz, size_precision)
.map_err(|e| anyhow::anyhow!("Failed to parse fill_sz='{}': {e}", msg.fill_sz,))?
} else if let Some(ref acc_fill_sz) = msg.acc_fill_sz {
// If fillSz is missing but accFillSz is available, calculate incremental fill
if !acc_fill_sz.is_empty() && acc_fill_sz != "0" {
let current_filled = parse_quantity(acc_fill_sz, size_precision).map_err(|e| {
anyhow::anyhow!("Failed to parse acc_fill_sz='{acc_fill_sz}': {e}",)
})?;
// Calculate incremental fill as: current_total - previous_total
if let Some(prev_qty) = previous_filled_qty {
if current_filled < prev_qty {
anyhow::bail!(
"Cumulative fill went backwards: acc_fill_sz='{acc_fill_sz}' < previous_filled_qty={prev_qty} \
(possible stale data after reconnect)"
);
}
let incremental = current_filled - prev_qty;
if incremental.is_zero() {
log::debug!(
"Skipping duplicate fill: acc_fill_sz='{acc_fill_sz}' unchanged from previous={prev_qty}"
);
return Ok(None);
}
incrementalView on GitHub (pinned to 18893faf8b)
Solutions
- Refresh instrument definitions so size_precision covers the accFillSz decimals.
- Inspect the raw payload to confirm accFillSz is a valid non-negative number.
- Resync order state via REST to recover from the bad update.
- Patch the adapter's parse_quantity/model if OKX changed the format.
Defensive patterns
Strategy: validation
Validate before calling
// Rust: pre-validate accFillSz when fillSz is absent
fn acc_fill_sz_ok(acc: &Option<String>, precision: u32) -> bool {
acc.as_deref().map_or(true, |s| s.is_empty() || s == "0"
|| rust_decimal::Decimal::from_str(s).map(|d| d.is_sign_positive() && d.scale() as u32 <= precision).unwrap_or(false))
} Try / catch
match parse_fill_report(&msg, ...) {
Ok(r) => emit(r),
Err(e) => { log::warn!("accFillSz parse failed: {e}"); mark_order_dirty(&msg.inst_id); }
} Prevention
- Refresh lotSz/size_precision before subscribing; stale specs are the top cause.
- Verify newly listed instruments are re-fetched before trading them.
- Compare REST fill history against stream fills to detect silent parse drops.
When it happens
Trigger: parse_fill_report gets an order update where fill_sz is empty/"0", acc_fill_sz (Option) is Some and non-empty/!="0", but parse_quantity(acc_fill_sz, size_precision) fails — non-numeric, negative, or finer precision than size_precision.
Common situations: Instrument definitions cached before an OKX lotSz change; accFillSz arriving with more decimals than the instrument allows; partially-filled order pushes on newly listed instruments with locally stale specs.
Understand the failure class
Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.
- Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.
Related errors
- Failed to parse fill_sz='{}': {e}
- Failed to parse fallback quantity for ord_id={}, sz='{}': {e
- Failed to convert quote-to-base quantity for ord_id={}, sz={
- Failed to parse filled quantity for ord_id={}, acc_fill_sz='
- Failed to parse base quantity for ord_id={}, sz='{}': {e}
AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08).
Data as JSON: /api/errors/210fc456416f5f75.
Report an issue: GitHub.