t8y2/dbx · warning

close Hive initFile statement result: %w

Error message

close Hive initFile statement result: %w

What it means

Error from `runHiveInitStatements` when `rows.Close()` returns a non-nil error after successfully draining an initFile statement's result set. The close error is wrapped with %w and returned; it is the rarest of the three init-statement errors and usually reflects the underlying Hive driver's connection being in a bad state when releasing the result set.

Source

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

}

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
	case "list_schemas":
		result, err := server.listSchemas(stringSliceParam(params, "visible_schemas"))
		return result, false, err

View on GitHub (pinned to c0390bff16)

Solutions

  1. Unwrap (%w) and check whether Close failed due to context cancellation — if so, increase the connect timeout; the statement itself succeeded, so this is usually benign.
  2. Upgrade the Hive database/sql driver; several versions leak errors from rows.Close after server-side connection aborts.
  3. Ensure nothing closes the shared *sql.Conn concurrently while init statements run (openConnection holds connectionMu, but external cancel() can fire).
  4. Retry the connection open; a failed Close after a successful read rarely indicates a bad init statement.

Example fix

// before
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second) // too tight
// after
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second) // allow drain+close to finish
Defensive patterns

Strategy: try-catch

Try / catch

err := runHiveInitStatements(ctx, conn, stmts, fetchSize)
if err != nil {
    var closeErr error
    if errors.As(err, &closeErr) && strings.Contains(err.Error(), "close Hive initFile statement result") {
        log.Printf("init statement read succeeded but rows.Close failed (likely benign): %v", err)
        return nil // or reconnect once if the conn is now unusable
    }
    return err
}

Prevention

When it happens

Trigger: An initFile statement with a result set is drained without error, but `rows.Close()` fails — typically because the underlying *sql.Conn was concurrently closed or errored (context cancellation racing the drain, server already closed the connection) so the driver cannot cleanly release the rows.

Common situations: Connect timeout expiring just as the drain finishes so the context-cancelled connection fails on Close; Hive driver version bugs surfacing errors from Close after a server-side abort; connection pooling returning an already-broken conn.

Related errors


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