vectordotdev/vector · error

output driver task should not have panicked

Error message

output driver task should not have panicked

What it means

run_validation joins the output driver task and expects it to finish without panicking; its result is the collected output events. A panic here means the task collecting/validating events from the external resource crashed, so the validation run cannot produce results.

Solutions

1. Read the upstream panic message from the JoinError to locate the failing driver code.
2. Fix the sink/output configuration so emitted events match the expected schema.
3. Make the driver return Result instead of panicking on recoverable collection errors.

Example fix

// before
let output_events = output_driver.await.expect("output driver task should not have panicked");
// after
let output_events = output_driver.await.unwrap_or_else(|e| panic!("output driver panicked: {e}"));

match output_driver.await {
    Ok(events) => events,
    Err(join_err) => panic!("output driver panicked: {join_err}"),
}

When it happens

Trigger: The output driver panics while draining events — typically a decode/parse failure on received events, an assertion in the comparison logic, or the external resource connection erroring in a way the driver asserts cannot happen.

Common situations: A sink emitting events in an unexpected shape that the driver's decoder asserts on; network interruptions to the output resource; regressions in the output collection code.

Related errors

• input 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/6773e811de77055e. Report an issue: GitHub.

Appendix: source

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

            //
            // 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;

            info!("Collected runner metrics: {runner_metrics:?}");
            let final_runner_metrics = runner_metrics.lock().await;

            // Run the relevant data -- inputs, outputs, telemetry, etc -- through each validator to
            // get the validation results for this test.
            let TestCase {
                name: test_name,
                expectation,
                events: input_events,
                ..

View on GitHub (pinned to bdb87aeaa4)