googleapis/mcp-toolbox · error

error processing row: %w

Error message

error processing row: %w

What it means

Inside the Execute row callback, resultRow.GetByName(c.Name, &columValue) failed while decoding a column value into a generic any. This indicates a row-level deserialization problem — e.g. a column value whose type can't be scanned into the destination — rather than a query or network failure. The callback stores the error in rowErr and stops iteration; RunSQL then reports it wrapped with this message.

Source

Thrown at internal/sources/bigtable/bigtable.go:211

		for _, c := range cols {
			var columValue any
			if err = resultRow.GetByName(c.Name, &columValue); err != nil {
				rowErr = err
				return false
			}
			vMap[c.Name] = columValue
		}

		out = append(out, vMap)

		return true
	})
	if err != nil {
		return nil, fmt.Errorf("unable to execute client: %w", err)
	}
	if rowErr != nil {
		return nil, fmt.Errorf("error processing row: %w", rowErr)
	}

	return out, nil
}

func initBigtableClient(ctx context.Context, tracer trace.Tracer, name, project, instance string) (*bigtable.Client, error) {
	//nolint:all // Reassigned ctx
	ctx, span := sources.InitConnectionSpan(ctx, tracer, SourceType, name)
	defer span.End()

	// Set up Bigtable data operations client.
	poolSize := 10
	userAgent, err := util.UserAgentFromContext(ctx)
	if err != nil {
		return nil, err
	}

	client, err := bigtable.NewClient(ctx, project, instance, option.WithUserAgent(userAgent), option.WithGRPCConnectionPool(poolSize))

View on GitHub (pinned to 8cc6e09de2)

Solutions

  1. Read the wrapped GetByName error to identify the failing column and value type
  2. Scan the column into the specific Go type matching the column's SQL type instead of a generic any
  3. Skip/handle problematic columns defensively in the callback and continue processing remaining rows
  4. Check for recent schema/value-format changes on the table or column family

Example fix

// before
var columValue any
if err = resultRow.GetByName(c.Name, &columValue); err != nil { ... }
// after (scan into concrete type, e.g. string)
var columValue string
if err = resultRow.GetByName(c.Name, &columValue); err != nil { ... }
Defensive patterns

Strategy: try-catch

Try / catch

out, err := src.RunSQL(ctx, stmt, cfgParams, values)
if err != nil {
	if strings.Contains(err.Error(), "error processing row") {
		// row-level decode failure: inspect wrapped GetByName error,
		// log the offending column, and fall back to a narrower query
		log.Printf("row decode failed: %v", err)
	}
	return err
}

Prevention

When it happens

Trigger: During bs.Execute, the per-row callback calls resultRow.GetByName for each column in resultRow.Metadata.Columns; GetByName returns an error for that specific row/column, callback sets rowErr and returns false.

Common situations: Columns with Bigtable value types the generic decoding path can't handle (bytes/complex cells); schema changed so column types differ from expectations; nil/empty cells being scanned unexpectedly.

Related errors


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