vectordotdev/vector · error

should not fail to build current-thread runtime

Error message

should not fail to build current-thread runtime

What it means

The validation runner spawns a dedicated OS thread and builds a current-thread Tokio runtime inside it to drive the component topology. Building a Tokio runtime with enable_all() essentially never fails on a healthy system, so the code asserts success with expect. A failure here indicates a runtime/environment-level problem, not a problem with the component being validated.

Solutions

1. Check that Tokio is compiled with full features (rt, net, time, io) in the validation crate's dependency graph.
2. Raise the container's thread/process/fd limits and re-run the validation test.
3. Inspect the returned runtime error by replacing expect with unwrap_or_else to surface the underlying io error.

let rt = Builder::new_current_thread().enable_all().build();
assert!(rt.is_ok(), "tokio runtime unavailable: {:?}", rt.err());

match Builder::new_current_thread().enable_all().build() {
    Ok(rt) => rt,
    Err(e) => panic!("runtime init failed in validation thread: {e}"),
}

When it happens

Trigger: Builder::new_current_thread().enable_all().build() returning an error inside the spawned thread in spawn_component_topology — e.g. Tokio feature flags disabled at compile time, resource exhaustion (thread/fd limits), or an incompatible custom runtime setup in an embedded environment.

Common situations: Building Vector with a non-default Tokio feature set that lacks the needed drivers, running tests in a heavily constrained container hitting thread/process limits, or embedding the validation runner in another binary with altered runtime assumptions.

Related errors

• Unable to create async runtime
• concurrent map task cancelled outside of our control
• double thread initialization
• Failed to set up SIGHUP handler.
• Failed to set up SIGINT handler.

AI-assisted analysis of vectordotdev/vector@bdb87aeaa4 (2026-09-16). Data as JSON: /api/errors/9c2d6ad4370473a4. Report an issue: GitHub.

Appendix: source

Thrown at src/components/validation/runner/mod.rs:531

) {
    let topology_started = topology_task_coordinator.track_started();
    let topology_completed = topology_task_coordinator.track_completed();
    let mut topology_shutdown_handle = topology_task_coordinator.register_for_shutdown();

    let mut config = config_builder
        .build()
        .expect("config should not have any errors");

    // It's possible we could extend the framework to allow specifying logic to
    // handle that, but I don't see much value currently since the healthcheck is
    // not enforced for components, and it doesn't impact the internal telemetry.
    config.healthchecks.enabled = false;

    _ = std::thread::spawn(move || {
        let test_runtime = Builder::new_current_thread()
            .enable_all()
            .build()
            .expect("should not fail to build current-thread runtime");

        test_runtime.block_on(async move {
            info!("Building component topology...");

            let (topology, mut crash_rx) =
                RunningTopology::start_init_validated(config, extra_context)
                    .await
                    .unwrap();

            info!("Component topology built and spawned.");
            topology_started.mark_as_done();

            select! {
                // We got the signal to shutdown, so stop the topology gracefully.
                _ = topology_shutdown_handle.wait() => {
                    info!("Shutdown signal received, stopping topology...");
                    topology.stop().await;
                    info!("Component topology stopped gracefully.")

View on GitHub (pinned to bdb87aeaa4)