alibaba/open-code-review · warning
telemetry shutdown: %v
Error message
telemetry shutdown: %v
What it means
Aggregated error returned by telemetry.Shutdown when one or more registered telemetry provider shutdown functions (OTLP exporters, etc.) fail while flushing buffered data. All shutdown funcs are executed, every failure is collected, and the combined errors are wrapped into a single 'telemetry shutdown: ...' error. Shutdown funcs are cleared afterwards, so a second Shutdown call is a no-op.
Source
Thrown at internal/telemetry/shutdown.go:30
// Shutdown flushes and shuts down all initialized providers.
// It should be called before process exit to ensure buffered data is exported.
func Shutdown(ctx context.Context) error {
if len(shutdownFuncs) == 0 {
return nil
}
var errs []error
for _, fn := range shutdownFuncs {
if err := fn(ctx); err != nil {
errs = append(errs, err)
}
}
shutdownFuncs = nil
if len(errs) > 0 {
return fmt.Errorf("telemetry shutdown: %v", errs)
}
return nil
}
// ShutdownWithTimeout creates a timeout context and calls Shutdown.
func ShutdownWithTimeout(ctx context.Context, timeout time.Duration) {
cctx, cancel := context.WithTimeout(ctx, timeout)
defer cancel()
if err := Shutdown(cctx); err != nil {
fmt.Fprintf(os.Stderr, "[ocr] WARNING: telemetry shutdown error: %v\n", err)
}
}
View on GitHub (pinned to 5cf97d0d15)
Solutions
- Read the wrapped errors after 'telemetry shutdown:' to identify which exporter failed and why.
- Increase the timeout passed to ShutdownWithTimeout so buffered spans/metrics can flush.
- Verify the telemetry endpoint/collector is reachable; check proxy and firewall settings.
- Treat as non-fatal if the review result itself is fine — the CLI already logs this as a WARNING to stderr in ShutdownWithTimeout.
Example fix
// before telemetry.Shutdown(context.Background()) // after telemetry.ShutdownWithTimeout(context.Background(), 10*time.Second) // longer window to flush exporters
Defensive patterns
Strategy: try-catch
Validate before calling
// no pre-call validation possible; optionally check telemetry was initialized
if len(shutdownFuncs) == 0 { return nil } Try / catch
if err := telemetry.Shutdown(ctx); err != nil {
// aggregated: 'telemetry shutdown: [err1 err2]'
log.Printf("telemetry did not flush cleanly (non-fatal): %v", err)
} Prevention
- Give ShutdownWithTimeout a generous timeout (>=10s) so exporters can flush.
- Ensure the telemetry endpoint/collector is reachable before the run.
- Call Shutdown exactly once at exit; it is idempotent only as a no-op afterwards.
- Monitor collector health; treat this error as observability loss, not run failure.
When it happens
Trigger: Calling telemetry.Shutdown(ctx) (or ShutdownWithTimeout) at process exit when a provider's shutdown function returns an error — typically a context deadline exceeded while flushing to a remote collector, or an exporter connection failure.
Common situations: Network unreachable or telemetry endpoint down at exit; the shutdown timeout (ShutdownWithTimeout) is too short for large buffered batches; the collector rejects the final export.
Related errors
- llm request failed: %w
- [ocr] Subtask error for group %q: %v
- invalid boolean for telemetry.enabled: %w
- invalid boolean for telemetry.content_logging: %w
- scan failed: %w
AI-assisted analysis of alibaba/open-code-review@5cf97d0d15 (2026-09-02).
Data as JSON: /api/errors/2f59ed2700c64730.
Report an issue: GitHub.