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
- Inspect the wrapped error (%w): if it is a connection/IO error, reconnect and retry the call.
- 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.
- Test the same catalog query manually in psql/vsql to see whether a column returns NULL or an unexpected value.
- 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
- Use a stable network path / connection pool settings so result sets are not truncated by idle disconnects.
- Match driver version to server version; catalog column layout changes between releases cause Scan failures.
- If you customize catalog queries, mirror any nullable columns with sql.Null* scan targets.
- Test metadata reads against your exact Vastbase version in CI to catch scanning mismatches early.
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
- routine source is not supported for %s connections
- list custom types in schema %q: %w
- failed to locate custom type %s.%s: %w
- failed to read enum values: %w
- failed to read composite fields: %w
AI-assisted analysis of t8y2/dbx@c0390bff16 (2026-09-05).
Data as JSON: /api/errors/dec94cdaf6c5c164.
Report an issue: GitHub.