argoproj/argo-workflows · critical

Artifact driver connection validation failed: %v

Error message

Artifact driver connection validation failed: %v

What it means

During argo-server startup, Run calls validateArtifactDriverConnections which attempts a real connection for each configured artifact driver (S3, GCS, Azure, etc.). If any driver fails its connectivity check, the collected errors are joined into this message and server startup aborts.

Source

Thrown at server/apiserver/argoserver.go:551

			log.WithField("driver", driver.Name).Info(ctx, "Successfully validated connection to artifact driver")
		})
	}

	// Wait for all validations to complete
	wg.Wait()
	close(errorChannel)

	// Collect any errors
	var connectionErrors []string
	for err := range errorChannel {
		connectionErrors = append(connectionErrors, err.Error())
	}

	if len(connectionErrors) > 0 {
		errorMsg := fmt.Sprintf("Artifact driver connection validation failed: %v", connectionErrors)
		log.WithField("errors", connectionErrors).Error(ctx, errorMsg)
		return errors.New(errorMsg)
	}

	log.WithField("driverCount", len(cfg.ArtifactDrivers)).Info(ctx, "Artifact driver connection validation passed: All configured artifact drivers are accessible")
	return nil
}

// validateArtifactDriverImages validates that the artifact driver images are present in the server pod
func (as *argoServer) validateArtifactDriverImages(ctx context.Context, cfg *config.Config) error {
	log := logging.RequireLoggerFromContext(ctx)
	if len(cfg.ArtifactDrivers) == 0 {
		log.Info(ctx, "No artifact drivers configured, skipping validation")
		return nil
	}

	log.Info(ctx, "Validating artifact driver images against server pod")

	// Get the current pod name using the standard Argo pattern
	podName, err := k8sutil.GetCurrentPodName(ctx, as.clients.Kubernetes, as.namespace, "app=argo-server")

View on GitHub (pinned to 35bff19146)

Solutions

  1. Read the embedded connectionErrors list in the message to see which driver(s) failed and their underlying cause.
  2. Fix the artifact repository config (endpoint, bucket, region, keys) used by the argo-server pod.
  3. Verify credentials/secret mounts exist in the argo-server deployment and are current.
  4. Test connectivity from inside the server pod (e.g. `kubectl exec` + curl/nc to the storage endpoint).
  5. If a driver is unused, remove it from config so it isn't validated.

Example fix

# before (wrong endpoint in artifact config)
s3:
  endpoint: minio:9001
# after
s3:
  endpoint: minio:9000
  bucket: my-bucket
  accessKeySecret: {name: minio, key: accesskey}
  secretKeySecret: {name: minio, key: secretkey}
Defensive patterns

Strategy: try-catch

Validate before calling

// before starting argo-server, verify storage endpoints
conn, err := net.DialTimeout("tcp", "minio:9000", 5*time.Second)
if err != nil {
    return fmt.Errorf("artifact storage unreachable: %w", err)
}
conn.Close()

Try / catch

if err := server.Run(ctx); err != nil {
    if strings.Contains(err.Error(), "Artifact driver connection validation failed") {
        log.Printf("check artifact repo config/credentials: %v", err)
        // fix config, then restart
    }
    return err
}

Prevention

When it happens

Trigger: Starting `argo server` (or the argo-server pod starting) with artifact drivers configured whose backing storage is unreachable: wrong endpoint/bucket names, missing or expired credentials, network policy / egress blocks, or a local dev stack where MinIO isn't up.

Common situations: Misconfigured artifactRepository in workflow-controller-configmap for the server; S3 endpoint typos or wrong port (e.g. minio:9000 not exposed); IAM/secret keys absent in the server pod; firewalls blocking outbound storage traffic; driver enabled in config but its service not deployed.

Related errors


AI-assisted analysis of argoproj/argo-workflows@35bff19146 (2026-09-03). Data as JSON: /api/errors/384a61af5daa3599. Report an issue: GitHub.