t8y2/dbx · error

failed to read type %s.%s: %w

Error message

failed to read type %s.%s: %w

What it means

After locating the type's catalog row, this error wraps failures that occur while advancing or scanning the result set (vastbase_metadata.go:617-618 and 628-629). It means the row was found but its contents could not be read — either the driver hit an I/O/protocol error iterating rows (rows.Err()) or the row's column values could not be scanned into the expected Go types (int64/string/bool/NullString).

Source

Thrown at agents/drivers/vastbase-go/vastbase_metadata.go:618

	}
	if isSystemSchema(schema) {
		return nil, fmt.Errorf("system schema %s is not supported for custom type details", schema)
	}
	catalog := "sys_catalog"
	if s.mode.postgresCatalog {
		catalog = "pg_catalog"
	}
	prefix := catalogPrefix(catalog)
	queries := customTypeCatalogQueriesFor(catalog, prefix, schema, name)

	rows, err := s.metadataQuery(queries.general)
	if err != nil {
		return nil, fmt.Errorf("failed to locate custom type %s.%s: %w", schema, name, err)
	}
	defer rows.Close()
	if !rows.Next() {
		if err := rows.Err(); err != nil {
			return nil, fmt.Errorf("failed to read type %s.%s: %w", schema, name, err)
		}
		return nil, fmt.Errorf("custom type %s.%s does not exist", schema, name)
	}
	var oid, typbasetype, typrelid, typelem, typcollation int64
	var typtype, typalign, typstorage string
	var typisdefined, typnotnull, typbyval bool
	var typdefaultbin, typdefault, inputFn, outputFn, receiveFn, sendFn, analyzeFn, comment, collname, relkind sql.NullString
	var typlen sql.NullInt64
	var typtypmod int64
	if err := rows.Scan(&oid, &typtype, &typisdefined, &typbasetype, &typnotnull, &typrelid, &typelem, &typcollation, &typdefaultbin, &typdefault, &typlen, &typbyval, &typalign, &typstorage, &typtypmod, &inputFn, &outputFn, &receiveFn, &sendFn, &analyzeFn, &comment, &relkind, &collname); err != nil {
		return nil, fmt.Errorf("failed to read type %s.%s: %w", schema, name, err)
	}
	if err := rows.Close(); err != nil {
		return nil, err
	}
	if !typisdefined {
		return nil, fmt.Errorf("custom type %s.%s is not fully defined", schema, name)
	}

View on GitHub (pinned to c0390bff16)

Solutions

  1. Inspect the wrapped error (%w): if it is a connection/IO error, reconnect and retry the call.
  2. If it is a Scan type error, check the server version's catalog column types and update the driver (or its scan targets) to match.
  3. Test the same catalog query manually in psql/vsql to see whether a column returns NULL or an unexpected value.
  4. Upgrade the vastbase-go driver to a version that handles your server's catalog layout (mode detection via postgresCatalog may need to be correct).

Example fix

// before
var typalign string
rows.Scan(..., &typalign, ...) // fails: NULL in typalign
// after
var typalign sql.NullString
rows.Scan(..., &typalign, ...)
align := typalign.String
Defensive patterns

Strategy: try-catch

Try / catch

details, err := s.getTypeDetails(schema, name)
if err != nil {
    if strings.Contains(err.Error(), "failed to read type ") {
        var root error = err
        for errors.Unwrap(root) != nil { root = errors.Unwrap(root) }
        if isTransient(root) { // connection dropped mid-result: retry once
            return s.getTypeDetails(schema, name)
        }
        return nil, fmt.Errorf("catalog row for %s.%s unreadable (server version/driver mismatch?): %w", schema, name, root)
    }
    return nil, err
}

Prevention

When it happens

Trigger: rows.Err() returns non-nil during iteration (connection lost mid-result, server error streamed after the row), or rows.Scan fails because a catalog column has an unexpected type or NULL where a typed value was expected (e.g. NULL in typalign on a nonstandard server, driver type-mapping differences).

Common situations: Network interruption while the result set streams; running against a server version whose pg_type/sys_type columns differ (NULLs or different types); driver-level scanning quirks for Vastbase-specific column types.

Related errors


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