vectordotdev/vector · critical
ServiceSink service sender dropped.
Error message
ServiceSink service sender dropped.
What it means
ServiceSink::poll_complete panics when an in-flight request future completes with Err, which in this driver means the bounded service sender (mpsc) was dropped while requests were outstanding. The sink assumes the spawned service task stays alive for the sink's lifetime; its disappearance is treated as an unrecoverable internal failure. The original service error was collapsed into the channel-closed error, so the root cause is the service task dying (often a panic or shutdown in the service stack).
Solutions
- Look for an earlier panic/error log from the inner service task — that is the real root cause
- Fix the underlying service failure (e.g. encoding, network) that killed the task
- If seen in custom code, keep the service alive until all in-flight futures resolve, and drain the sink before dropping
Defensive patterns
Strategy: try-catch
Validate before calling
// Verify the inner service task is alive before driving the sink assert!(!service_handle.is_finished(), "service task must outlive ServiceSink");
Try / catch
// Catch the upstream service failure that kills the task:
match sink_future.await {
Ok(()) => {},
Err(e) => error!(error = %e, "sink driver failed; check inner service task panic"),
} Prevention
- Keep the service task alive until all in-flight requests complete
- Drain/flush the sink before shutdown
- Investigate any earlier panic in the service stack — it is the root cause
When it happens
Trigger: The inner Tower service task panics or exits while ServiceSink still has requests in flight; the sink's service sender is dropped during driver teardown out of order.
Common situations: A panic deeper in the sink's service stack (e.g. serialization error) tears down the service task; improper shutdown sequencing in custom drivers or during vector reload/shutdown races.
Understand the failure class
Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.
Related errors
- building HTTP request failed unexpectedly
- Failed type coercion
- Failed type coercion
- global log_schema.source_type_key to be valid path
- HTTP status codes are valid u16 values
AI-assisted analysis of vectordotdev/vector@bdb87aeaa4 (2026-09-16).
Data as JSON: /api/errors/6bbf5fb2b6368a11.
Report an issue: GitHub.
Appendix: 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 bdb87aeaa4)