What causes "Loading signals from Redis cache adapter not supported" in nautechsystems/nautilus_trader?

Use a different backing store (e.g. PostgreSQL/postgres cache adapter) for signal persistence and loading.

Loading signals from Redis cache adapter not supported

Error message

Loading signals from Redis cache adapter not supported

What it means

The Redis cache adapter implements load_signals as an explicit bail: it deliberately does not support reading signals back from Redis. Any call to the Cache's load_signals when backed by this adapter returns this error unconditionally. Signals are expected to be persisted/loaded through other backends.

Source

Thrown at crates/infrastructure/src/redis/cache.rs:1587

            &self.database.trader_key,
            position_id,
            self.encoding(),
        )
        .await
    }

    fn load_actor(&self, actor_id: &ActorId) -> anyhow::Result<AHashMap<String, Bytes>> {
        let key = format!("{ACTORS}{REDIS_DELIMITER}{actor_id}{REDIS_DELIMITER}state");
        self.load_state(key)
    }

    fn load_strategy(&self, strategy_id: &StrategyId) -> anyhow::Result<AHashMap<String, Bytes>> {
        let key = format!("{STRATEGIES}{REDIS_DELIMITER}{strategy_id}{REDIS_DELIMITER}state");
        self.load_state(key)
    }

    fn load_signals(&self, _name: &str) -> anyhow::Result<Vec<Signal>> {
        anyhow::bail!("Loading signals from Redis cache adapter not supported")
    }

    fn load_custom_data(&self, data_type: &DataType) -> anyhow::Result<Vec<CustomData>> {
        self.database.load_custom_data(data_type)
    }

    fn load_order_snapshot(
        &self,
        _client_order_id: &ClientOrderId,
    ) -> anyhow::Result<Option<OrderSnapshot>> {
        anyhow::bail!("Loading order snapshots from Redis cache adapter not supported")
    }

    fn load_position_snapshot(
        &self,
        _position_id: &PositionId,
    ) -> anyhow::Result<Option<PositionSnapshot>> {
        anyhow::bail!("Loading position snapshots from Redis cache adapter not supported")

View on GitHub (pinned to 18893faf8b)

Solutions

Use a different backing store (e.g. PostgreSQL/postgres cache adapter) for signal persistence and loading.
Restructure the workflow so signals are regenerated or passed in-process rather than reloaded from Redis.
Catch the error and treat it as 'no signals available' if signal replay is optional for your run.
Track the adapter's feature support and feature-gate signal loading code paths.

Example fix

// before
let signals = cache.load_signals("my_strategy")?; // bails on Redis
// after
let signals = cache.load_signals("my_strategy").unwrap_or_default(); // tolerate unsupported load

Defensive patterns

Strategy: fallback

Validate before calling

// Python
if isinstance(cache_database, RedisCacheDatabase):
    signals = []  # Redis adapter cannot load signals
else:
    signals = cache.load_signals(name)

Try / catch

// Python
try:
    signals = cache.load_signals(name)
except RuntimeError as e:
    if "not supported" in str(e) and "signals" in str(e):
        signals = []
    else:
        raise

Prevention

Do not rely on Redis cache for signal persistence; use a data catalog or postgres adapter.
Feature-gate signal-replay code paths by backend capability.
Document adapter limitations in deployment configs.

When it happens

Trigger: Calling cache.load_signals(name) (directly or via strategies/workflows that restore state on startup) while the cache database is the Redis adapter.

Common situations: Live/trading runs configured with the Redis cache attempting signal replay on restart; switching a backtest script that relied on in-memory or another adapter to Redis and expecting load_signals to work; recovery workflows assuming full state restore.

Related errors

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