nautechsystems/nautilus_trader · error

LiveNode::add_plugin requires host-side plug-in support; nau

Error message

LiveNode::add_plugin requires host-side plug-in support; nautilus-plugin is the guest SDK only

What it means

LiveNode::add_plugin always errors when host-side plug-in support is absent; this build only has the nautilus-plugin guest SDK, so no plug-in can ever be registered. The method exists for API compatibility but is unsupported here.

Source

Thrown at crates/live/src/node/mod.rs:343

        )
    }

    /// Loads and registers one plug-in instance.
    ///
    /// # Errors
    ///
    /// Returns an error because dynamic plug-in hosting lives in the host-side integration.
    #[expect(
        clippy::needless_pass_by_value,
        reason = "signature mirrors the host-enabled API"
    )]
    pub fn add_plugin(&mut self, config: PluginConfig) -> anyhow::Result<()> {
        #[cfg(feature = "plugin")]
        config.validate_runtime_support(self.config.plugins.len())?;
        #[cfg(not(feature = "plugin"))]
        let _ = config;

        anyhow::bail!(
            "LiveNode::add_plugin requires host-side plug-in support; nautilus-plugin is the guest SDK only"
        )
    }

    /// Returns a thread-safe handle to control this node.
    #[must_use]
    pub fn handle(&self) -> LiveNodeHandle {
        self.handle.clone()
    }

    /// Adds a callback for supported typed external messages.
    ///
    /// While [`run`](Self::run) or [`run_with_mode`](Self::run_with_mode) services external ingress,
    /// the node invokes processors in registration order before normal inbound streaming filters
    /// for JSON or MessagePack payloads when [`msgbus::BusPayloadType::is_typed_message`] returns
    /// `true`. Other encodings are skipped with a warning. Each callback receives the decoded
    /// concrete value as [`Any`], allowing it to downcast to the concrete payload type. External
    /// egress is suppressed while the processors run, so synchronous publications remain local.

View on GitHub (pinned to 18893faf8b)

Solutions

  1. Do not call add_plugin in this build; remove the call.
  2. Enable host-side plug-in support (compile with the plugin host feature) if plug-ins are required.
  3. Fold the plug-in's behavior directly into the node code instead.

Example fix

// before
node.add_plugin(plugin_config)?;
// after
// removed: plug-ins unsupported without host-side plugin support
Defensive patterns

Strategy: type-guard

Validate before calling

if !cfg!(feature = "plugin") { /* add_plugin unsupported in this build */ }

Type guard

fn supports_plugins() -> bool { cfg!(feature = "plugin") }

Prevention

When it happens

Trigger: Calling LiveNode::add_plugin(config) on a node built without the `plugin` (host-side) feature.

Common situations: Following plug-in documentation or examples while running a Rust build without host plug-in support; assuming add_plugin works because the method exists.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


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