t8y2/dbx · error

read Hive initFile statement result: %w

Error message

read Hive initFile statement result: %w

What it means

Error from `runHiveInitStatements` when iterating/draining a result set of an initFile statement succeeded mechanically but `rows.Err()` then reports a deferred iteration error (e.g. the connection broke mid-drain or the driver surfaced a late error). The rows are closed (error ignored) and the underlying rows.Err() value is wrapped with %w. It is distinct from the 'execute ...' error (statement submission failed) and the 'close ...' error (rows.Close() failed): here the read loop itself failed.

Source

Thrown at agents/drivers/argo-go/main.go:381

		timeout += server.config.BrowserResponseTimeout
	}
	return timeout
}

func runHiveInitStatements(ctx context.Context, connection *sql.Conn, statements []string, fetchSize int) error {
	for _, statement := range statements {
		rows, _, hasResultSet, err := executeHiveStatement(ctx, connection, statement, fetchSize)
		if err != nil {
			return fmt.Errorf("execute Hive initFile statement: %w", err)
		}
		if !hasResultSet {
			continue
		}
		for rows.Next() {
		}
		if rowsErr := rows.Err(); rowsErr != nil {
			_ = rows.Close()
			return fmt.Errorf("read Hive initFile statement result: %w", rowsErr)
		}
		if closeErr := rows.Close(); closeErr != nil {
			return fmt.Errorf("close Hive initFile statement result: %w", closeErr)
		}
	}
	return nil
}

func (server *server) dispatch(method string, params map[string]json.RawMessage) (any, bool, error) {
	switch method {
	case "validate_connection":
		return map[string]bool{"ok": true}, false, server.validateConnection()
	case "connection_info":
		result, err := server.connectionInfo()
		return result, false, err
	case "list_databases":
		result, err := server.listDatabases()
		return result, false, err

View on GitHub (pinned to c0390bff16)

Solutions

  1. Unwrap (%w) the rows.Err() cause; if it is a timeout/cancellation, increase the connection open timeout or make init statements cheap.
  2. Replace result-returning init statements (SELECT/SHOW) with non-result statements (SET/USE/DDL) so nothing needs draining.
  3. Raise fetchSize to reduce round trips when draining is unavoidable, and stabilize connectivity (keepalives, LB idle timeout).
  4. Retry the connection open — this is often transient; the driver already closed rows and connection, so a fresh openConnection is safe.

Example fix

// before (initFile)
SELECT * FROM audit_log;  -- large result set drained at connect
// after
SET hive.exec.dynamic.partition=true;
USE audit;  -- no result set to drain
Defensive patterns

Strategy: retry

Validate before calling

// avoid result-returning statements in initFile
for _, stmt := range initStatements {
    if isResultStatement(stmt) { // SELECT/SHOW/DESCRIBE
        log.Printf("init statement returns a result set and will be drained at connect: %q", stmt)
    }
}

Try / catch

var lastErr error
for attempt := 0; attempt < 3; attempt++ {
    err := server.openConnection()
    if err == nil { break }
    lastErr = err
    if !isTransientReadError(err) { return err } // only retry drain/read failures
    time.Sleep(backoff(attempt))
}
return lastErr

Prevention

When it happens

Trigger: An initFile statement that returns a result set (hasResultSet true); the `for rows.Next()` drain loop runs, and afterwards `rows.Err()` is non-nil — network drop between server and driver during result streaming, context cancellation/deadline exceeded mid-iteration, or Hive server-side failure while producing rows.

Common situations: Init statements accidentally left as full SELECTs over large tables so streaming times out; unstable network or load balancer idle-kill during drain; fetchSize too small causing long paginated reads that exceed timeouts; Hive server restarting mid-connect.

Related errors


AI-assisted analysis of t8y2/dbx@c0390bff16 (2026-09-05). Data as JSON: /api/errors/4181a81e9cfed013. Report an issue: GitHub.