vectordotdev/vector · error

input driver task should not have panicked

Error message

input driver task should not have panicked

What it means

run_validation joins the input driver task and expects it to have completed without panicking. Since the JoinHandle::await returns Err only when the task panicked, this panic means the input driver (which feeds synthetic events into the pipeline) crashed — the expect converts that panic into a fatal error in the validation run.

Solutions

1. Look at the panic message printed by the joined task above this expect to find the root cause.
2. Fix the input configuration (event format, target address, rate) that made the driver panic.
3. Temporarily capture the JoinError with into_result() to log driver output before failing.

Example fix

// before
input_driver.await.expect("input driver task should not have panicked");
// after
if let Err(e) = input_driver.await { panic!("input driver panicked: {e}"); }

match input_driver.await {
    Ok(()) => (),
    Err(join_err) => panic!("input driver panicked: {join_err}"),
}

When it happens

Trigger: The future driving input events (synthetic input, interlinger/Loops-style generator) panics — e.g. division by zero in a batching config, unreachable socket for a client driver, or an assertion inside the input generator.

Common situations: Invalid input parameters (event rate, format) that a generator asserts on; connecting to an input endpoint that rejected/dropped the client; generator code regression after a refactor.

Related errors

• output driver task should not have panicked
• should not fail to send output event
• a sink must always have an external resource
• a source must always have an external resource
• breaking fragment ' ' has an invalid anchor ' '. Add ` }`…

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

Appendix: source

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

                output_rx,
                &runner_metrics,
                maybe_runner_encoder.as_ref().cloned(),
                self.configuration.component_type,
                expected_output_events,
            );

            // At this point, the component topology is running, and all input/output/telemetry
            // tasks are running as well. Our input driver should be sending (or will have already
            // sent) all of the input events, which will cascade through the component topology as
            // they're processed.
            //
            // We'll trigger each phase to shutdown, in order, to deterministically ensure each
            // section has completed. We additionally wait for the input driver task to complete
            // first, and the output driver task to complete last, as those tasks are freerunning
            // and don't require special shutdown coordination.
            input_driver
                .await
                .expect("input driver task should not have panicked");

            // Synchronize the shutdown of all tasks, and get the resulting output events.
            // We drive the shutdown by ensuring that the output events have been
            // processed by the external resource, which ensures that the input events have travelled
            // all the way through the pipeline, and that the telemetry events have been processed
            // before shutting down the telemetry and topology tasks.
            input_task_coordinator.shutdown().await;

            let output_events = output_driver
                .await
                .expect("output driver task should not have panicked");

            // Now that all output events have been received, we can shutdown the controlled edge/sink
            output_task_coordinator.shutdown().await;

            // as well as the telemetry and topology
            telemetry_task_coordinator.shutdown().await;
            topology_task_coordinator.shutdown().await;

View on GitHub (pinned to bdb87aeaa4)