googleapis/mcp-toolbox · error

errors encountered during query execution or row processing:

Error message

errors encountered during query execution or row processing: %w

What it means

Returned by the cloud-sql-mssql source's RunSQL after row iteration completes, when results.Err() reports a deferred error from the query execution or the row-iteration stream. Unlike a Scan failure, this catches errors surfaced lazily by the driver after streaming rows (e.g. server-side execution errors on multi-result statements or mid-stream connection loss). It is the last chance error check before results are returned.

Source

Thrown at internal/sources/cloudsqlmssql/cloud_sql_mssql.go:151

		}

		for results.Next() {
			scanErr := results.Scan(values...)
			if scanErr != nil {
				return nil, fmt.Errorf("unable to parse row: %w", scanErr)
			}
			row := orderedmap.Row{}
			for i, name := range cols {
				row.Add(name, rawValues[i])
			}
			out = append(out, row)
		}
	}

	// Check for errors from iterating over rows or from the query execution itself.
	// results.Close() is handled by defer.
	if err := results.Err(); err != nil {
		return nil, fmt.Errorf("errors encountered during query execution or row processing: %w", err)
	}

	return out, nil
}

func initCloudSQLMssqlConnection(ctx context.Context, tracer trace.Tracer, name, project, region, instance, ipType, user, pass, dbname string) (*sql.DB, error) {
	//nolint:all // Reassigned ctx
	ctx, span := sources.InitConnectionSpan(ctx, tracer, SourceType, name)
	defer span.End()

	userAgent, err := util.UserAgentFromContext(ctx)
	if err != nil {
		return nil, err
	}

	// Create dsn
	query := url.Values{}
	query.Add("app name", userAgent)

View on GitHub (pinned to 8cc6e09de2)

Solutions

  1. Read the wrapped error for the server-side SQL error number and message
  2. Split multi-statement batches into separate RunSQL calls to isolate the failing statement
  3. Add retry logic for transient errors (deadlock error 1205, timeouts)
  4. Tune query timeout / resource settings if statements are killed by the server
  5. Check instance logs in Cloud SQL for the server-side error

Example fix

// before
statement: "INSERT INTO t VALUES (1); SELECT * FROM nonexistent_table;"
// after
statement: "INSERT INTO t VALUES (1);"  // run separately
// and a second call: "SELECT * FROM existing_table;"
Defensive patterns

Strategy: retry

Try / catch

out, err := src.RunSQL(ctx, statement, params)
if err != nil && strings.Contains(err.Error(), "query execution or row processing") {
    if isTransient(err) { // e.g. deadlock 1205 or timeout
        time.Sleep(backoff)
        out, err = src.RunSQL(ctx, statement, params)
    }
}

Prevention

When it happens

Trigger: QueryContext returned a result set, Columns() succeeded (or was tolerated for DDL/DML), but results.Err() is non-nil after iteration — server-side error raised during result consumption (e.g. statement with multiple result sets where a later one fails, lock/timeout during streaming, connection reset).

Common situations: Batch/multi-statement SQL where an earlier statement succeeds and a later one fails, long-running result streams interrupted by network blips, query timeouts surfacing only after partial reads, deadlocks encountered mid-iteration.

Related errors


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