nautechsystems/nautilus_trader · error

post-only Derive orders only support GTC time in force; rece

Error message

post-only Derive orders only support GTC time in force; received {tif:?}

What it means

On Derive, post-only execution is expressed via a PostOnly time-in-force, which is only compatible with GTC. `time_in_force_to_derive` therefore accepts Gtc + post_only -> PostOnly, but if the order is post-only and the TIF is Ioc or Fok (which are mutually exclusive with resting on the book), it fails with this message.

Source

Thrown at crates/adapters/derive/src/common/parse.rs:192

        ),
        None => anyhow::bail!(
            "missing trigger price type for Derive trigger order; Derive trigger orders support only MarkPrice"
        ),
    }
}

/// Maps a Nautilus time-in-force flag to the Derive TIF.
///
/// # Errors
///
/// Returns an error for time-in-force flags Derive does not accept.
pub fn time_in_force_to_derive(
    tif: TimeInForce,
    post_only: bool,
) -> anyhow::Result<DeriveTimeInForce> {
    match tif {
        TimeInForce::Gtc if post_only => Ok(DeriveTimeInForce::PostOnly),
        TimeInForce::Ioc | TimeInForce::Fok if post_only => anyhow::bail!(
            "post-only Derive orders only support GTC time in force; received {tif:?}"
        ),
        TimeInForce::Gtc => Ok(DeriveTimeInForce::Gtc),
        TimeInForce::Ioc => Ok(DeriveTimeInForce::Ioc),
        TimeInForce::Fok => Ok(DeriveTimeInForce::Fok),
        other => anyhow::bail!("unsupported time in force for Derive: {other:?}"),
    }
}

/// Maps a Derive order side back to Nautilus.
#[must_use]
pub fn derive_order_side_to_nautilus(side: DeriveOrderSide) -> OrderSide {
    match side {
        DeriveOrderSide::Buy => OrderSide::Buy,
        DeriveOrderSide::Sell => OrderSide::Sell,
    }
}

View on GitHub (pinned to 18893faf8b)

Solutions

1. Drop post_only when using Ioc or Fok time in force (set post_only=false)
2. Switch the TIF to Gtc if post-only behavior (maker-only, never cross) is what the strategy actually needs
3. Add `validate_order_support` to pre-submission checks to reject this combination before hitting the venue

Example fix

// before
let tif = time_in_force_to_derive(TimeInForce::Ioc, true)?; // errors
// after
let tif = time_in_force_to_derive(TimeInForce::Gtc, true)?; // PostOnly
// or
let tif = time_in_force_to_derive(TimeInForce::Ioc, false)?; // Ioc, not post-only

fn valid_tif_post_only(tif: TimeInForce, post_only: bool) -> bool {
    !post_only || matches!(tif, TimeInForce::Gtc)
}

fn valid_tif_post_only(tif: TimeInForce, post_only: bool) -> bool {
    !post_only || matches!(tif, TimeInForce::Gtc)
}

match time_in_force_to_derive(tif, post_only) {
    Ok(t) => { /* build payload */ }
    Err(e) => tracing::warn!(%e, "post-only TIF conflict; falling back to GTC"),
}

When it happens

Trigger: Submitting, amending, or validating a Derive order (`order_to_derive_payload`, `order_replace_to_derive_payload`, `validate_order_support`) with `post_only = true` and `time_in_force` of Ioc or Fok — a contradictory combination since IOC/FOK imply immediate execution and cannot be post-only.

Common situations: Order builders that always set post_only=true from a default flag while the strategy sets IOC/FOK for aggressive fills; copying post-only Limit order templates into a FOK sweep strategy; multi-venue code where another exchange tolerates post_only with IOC/FOK.

Related errors

• missing trigger price type for Derive trigger order; Derive
• {FAILED}: {e}
• {FAILED}: {e}
• {FAILED}: {e}
• {FAILED}: {e}

AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08). Data as JSON: /api/errors/3caff1b4ceaf75b0. Report an issue: GitHub.