nautechsystems/nautilus_trader · error
KrakenHttpError (cloned per-order batch failure)
Error message
KrakenHttpError (cloned per-order batch failure)
What it means
When Kraken Futures submit_orders_batch sends a chunk of orders via the batch endpoint and the HTTP/API call itself fails, every order in that chunk gets the same cloned KrakenHttpError as its per-order result. All subsequent (not-yet-sent) chunks are marked NotAttempted and the loop breaks, so one transport failure fails the whole remaining batch.
Source
Thrown at crates/adapters/kraken/src/http/futures/client.rs:2530
Some(Some(status)) => Ok(FuturesBatchSubmitItem {
result: response_result,
status,
}),
Some(None) => Err(KrakenBatchOrderError::DuplicateResponse {
key: format!("order_tag {}", item.order_tag),
}
.into()),
None => Err(KrakenBatchOrderError::MissingResponse {
key: format!("order_tag {}", item.order_tag),
}
.into()),
};
results[*idx] = Some(result);
}
}
Err(e) => {
for (idx, _) in *chunk {
results[*idx] = Some(Err(anyhow::Error::new(e.clone())));
}
for later_chunk in &chunks[chunk_index + 1..] {
for (idx, _) in *later_chunk {
results[*idx] = Some(Err(KrakenBatchOrderError::NotAttempted.into()));
}
}
break;
}
}
}
results
.into_iter()
.map(|result| result.unwrap_or_else(|| Err(KrakenBatchOrderError::NotAttempted.into())))
.collect()
}
View on GitHub (pinned to 18893faf8b)
Solutions
- Inspect the wrapped KrakenHttpError for status/body to identify transport vs API rejection.
- Retry the failed chunk after a backoff; orders in later chunks are NotAttempted and safe to resubmit.
- Verify Kraken API key/secret validity and permissions before large batch submissions.
- Split very large batches to reduce blast radius per chunk; orders are NOT attempted after a chunk fails by design (fail-fast).
Example fix
// before
let results = client.submit_orders_batch(orders).await; // one bad chunk -> all later NotAttempted
// after
for chunk in orders.chunks(10) { let r = client.submit_orders_batch(chunk.to_vec()).await; /* retry per chunk */ } Defensive patterns
Strategy: retry
Validate before calling
// Rust: pre-check batch size and credentials before submitting assert!(orders.len() <= BATCH_ORDER_LIMIT); // verify credentials with a lightweight signed request first
Try / catch
let results = client.submit_orders_batch(orders).await;
for (i, r) in results.iter().enumerate() {
if let Err(e) = r {
if !format!("{e}").contains("NotAttempted") {
// retry single order i after backoff
}
}
} Prevention
- Keep chunks small to limit blast radius of one failed chunk
- Treat NotAttempted orders as safe to resubmit; failed-chunk orders need idempotency keys
- Backoff on 429 and honor Retry-After
- Verify API key permissions before batch trading
When it happens
Trigger: submit_orders_batch() where inner.submit_orders_batch(chunk) returns Err — network failure, 4xx/5xx from Kraken, auth error, or rate limiting on the batch endpoint.
Common situations: Submitting more than one order in a burst during network instability, expired API credentials (401), or hitting batch endpoint rate limits with large order groups.
Understand the failure class
Background: "API error: {status}" and "HTTP 401/403/404/429/5xx" errors: non-2xx HTTP responses explained — this error's family across 27 libraries.
Related errors
- KrakenHttpError (cloned per-order batch failure)
- Kraken Spot does not support the demo environment
- Modify order failed: {e}
- Either client_order_id or venue_order_id is required
- Trailing stop orders are not yet supported on the Kraken WS
AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08).
Data as JSON: /api/errors/823e2c3e0a1114eb.
Report an issue: GitHub.