googleapis/mcp-toolbox · error

unable to connect successfully: %w

Error message

unable to connect successfully: %w

What it means

This error is wrapped by SingleStore's Config.Initialize when pool.PingContext(ctx) fails after the connection pool was created. It means a pool object was constructed from the DSN, but the first real network round-trip to the SingleStore server failed, so the source cannot be considered usable. The pool is closed before returning the error, so the failure is terminal for initialization.

Source

Thrown at internal/sources/singlestore/singlestore.go:79

	ConnectionParams map[string]string `yaml:"connectionParams"`
}

// SourceConfigType returns the type of the source configuration.
func (r Config) SourceConfigType() string {
	return SourceType
}

// Initialize sets up the SingleStore connection pool and returns a Source.
func (r Config) Initialize(ctx context.Context, tracer trace.Tracer) (sources.Source, error) {
	pool, err := initSingleStoreConnectionPool(ctx, tracer, r)
	if err != nil {
		return nil, fmt.Errorf("unable to create pool: %w", err)
	}

	err = pool.PingContext(ctx)
	if err != nil {
		pool.Close()
		return nil, fmt.Errorf("unable to connect successfully: %w", err)
	}

	s := &Source{
		Config: r,
		Pool:   pool,
	}
	return s, nil
}

var _ sources.Source = &Source{}

// Source represents a SingleStore database source and holds its connection pool.
type Source struct {
	Config
	Pool *sql.DB
}

// SourceType returns the type of the source configuration.

View on GitHub (pinned to 8cc6e09de2)

Solutions

1. Verify the SingleStore endpoint (host, port) is reachable: run `nc -vz <host> <port>` or connect with the `mysql` CLI using the same credentials.
2. Check user, password, and database values in the toolbox config against the SingleStore portal / `SHOW DATABASES`.
3. Review connectionParams and tls settings; try `tls: "preferred"` vs `skip-verify` if certificates are self-signed.
4. Check that the SingleStore cluster is running and not suspended; restart it if paused.
5. Increase or fix queryTimeout-derived readTimeout if long pings time out on slow networks.

Example fix

// before (unreachable host)
kind: source
name: my_ss
host: internal-wrong-host
port: 3306
// after (correct endpoint)
kind: source
name: my_ss
host: my-cluster.svc.singlestore.com
port: 3306

// Pre-check reachability before Initialize
timeout, cancel := context.WithTimeout(ctx, 5*time.Second)
defer cancel()
conn, err := net.DialTimeout("tcp", net.JoinHostPort(cfg.Host, cfg.Port), 4*time.Second)
if err != nil { return fmt.Errorf("singlestore unreachable at %s:%s: %w", cfg.Host, cfg.Port, err) }
conn.Close()
_ = timeout

// Initialize returns (source, error); inspect the wrapped cause
src, err := cfg.Initialize(ctx, tracer)
if err != nil {
    var nerr net.Error
    if errors.As(err, &nerr) && nerr.Timeout() {
        // network/firewall/timeout path
    }
    if strings.Contains(err.Error(), "Access denied") {
        // credentials path
    }
    return fmt.Errorf("init failed: %w", err)
}

When it happens

Trigger: Initialize() calls initSingleStoreConnectionPool successfully (sql.Open is lazy), then PingContext(ctx) returns an error: server unreachable, bad credentials, unknown database, TLS negotiation failure, or context cancellation during the ping.

Common situations: Wrong host/port in the SingleStore config, firewall or VPC network blocking port 3306/3307, invalid user/password, database name that does not exist, SingleStore cluster paused or not yet provisioned, or TLS settings (tls=preferred/true) incompatible with the server.

Related errors

• unable to connect successfully: %w
• sql.Open: %w
• unable to connect successfully: %w
• unable to connect successfully: %w
• unable to create pool: %w

AI-assisted analysis of googleapis/mcp-toolbox@8cc6e09de2 (2026-09-05). Data as JSON: /api/errors/7fccf379903bf390. Report an issue: GitHub.