What causes "ServiceSink service sender dropped." in vectordotdev/vector?

Look upward in the logs: the first panic or error from the internal service task is the root cause - this panic merely reports it

vectordotdev/vector · error

ServiceSink service sender dropped.

Error message

ServiceSink service sender dropped.

What it means

ServiceSink drives sink requests through an internal service and tracks outstanding futures in self.in_flight. In poll_complete, a future resolving Err means the oneshot channel's sender - held by the internal service/driver task - was dropped, so pending responses can never arrive; the sink panics rather than silently pretending delivery succeeded.

Source

Thrown at src/sinks/util/sink.rs:482

                        });
                    }
                    _ => {} // do nothing
                }

                // If the rx end is dropped we still completed
                // the request so this is a weird case that we can
                // ignore for now.
                _ = tx.send(());
            })
            .instrument(info_span!("request", %request_id).or_current())
            .boxed()
    }

    fn poll_complete(&mut self, cx: &mut Context<'_>) -> Poll<()> {
        while !self.in_flight.is_empty() {
            match ready!(Pin::new(&mut self.in_flight).poll_next(cx)) {
                Some(Ok(())) => {}
                Some(Err(_)) => panic!("ServiceSink service sender dropped."),
                None => break,
            }
        }

        Poll::Ready(())
    }
}

impl<S, Request> fmt::Debug for ServiceSink<S, Request>
where
    S: fmt::Debug,
{
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        f.debug_struct("ServiceSink")
            .field("service", &self.service)
            .finish()
    }
}

View on GitHub (pinned to 3708c39b12)

Solutions

Look upward in the logs: the first panic or error from the internal service task is the root cause - this panic merely reports it
Run with RUST_BACKTRACE=1 under a supervisor to capture where the internal task died
Upgrade Vector - several shutdown/driver races around ServiceSink were fixed over time
If reproducible, open an issue with the config and logs from the first error to the panic

Defensive patterns

Strategy: try-catch

Try / catch

// You cannot pre-check this; contain it. Supervise the process so the panic is an
// observable failure: systemd 'Restart=on-failure' + Environment=RUST_BACKTRACE=1.
// In-process, watch the JoinError of the pipeline task:
let h = tokio::spawn(async move { run_topology(config).await });
if let Err(je) = h.await {
    if je.is_panic() { /* log backtrace, alert, restart pipeline with backoff */ }
}

Prevention

Run Vector under systemd or a supervisor with Restart=on-failure and RUST_BACKTRACE=1
Always triage the first error in the log, not this panic
Keep Vector updated - this class of internal race gets fixed regularly

When it happens

Trigger: The internal service driver task (e.g. the connection task behind NetworkService) panics or exits while requests are in flight; the inner service is dropped early during shutdown with un-drained in-flight requests.

Common situations: An earlier separate failure (connection error storm, task panic, OOM kill) took down the internal task and this panic is only the visible symptom; shutdown-ordering races between sink and driver in custom embeddings; bugs fixed across Vector releases.

Related errors

AI-assisted analysis of vectordotdev/vector@3708c39b12 (2026-08-20). Data as JSON: /api/errors/6bbf5fb2b6368a11. Report an issue: GitHub.