errors encountered during query execution or row processing:

Error message

errors encountered during query execution or row processing: %w

What it means

This error wraps rows.Err() checked after the row-iteration loop in the Oracle read path. database/sql defers row-fetch errors to rows.Err(), so failures that occurred while pulling rows from the server (network drops, server-side cursor errors, context cancellation mid-iteration) surface only here, after all locally buffered rows were processed.

Source

Thrown at internal/sources/oracle/oracle.go:256

			case *sql.RawBytes:
				if *v != nil {
					var unmarshaledData any
					if err := json.Unmarshal(*v, &unmarshaledData); err != nil {
						return nil, fmt.Errorf("unable to unmarshal json data for column %s", col)
					}
					vMap[col] = unmarshaledData
				} else {
					vMap[col] = nil
				}
			default:
				return nil, fmt.Errorf("unexpected receiver type: %T", v)
			}
		}
		out = append(out, vMap)
	}

	if err := rows.Err(); err != nil {
		return nil, fmt.Errorf("errors encountered during query execution or row processing: %w", err)
	}

	return out, nil
}

func buildGoOraConnString(user, password, connectStringBase, walletLocation string) string {
	userInfo := url.UserPassword(
		decodePercentEncodedUserInfo(user),
		decodePercentEncodedUserInfo(password),
	).String()

	base := fmt.Sprintf("oracle://%s@%s", userInfo, connectStringBase)
	trimmedWalletLocation := strings.TrimSpace(walletLocation)
	if trimmedWalletLocation == "" {
		return base
	}

	q := url.Values{}

View on GitHub (pinned to 8cc6e09de2)

Solutions

Inspect the wrapped %w ORA- code: ORA-01555 means increase undo retention or fetch in batches; network errors need connectivity fixes.
Increase the context timeout passed to RunSQL if cancellation is the cause, or page the query with ROWNUM/OFFSET-FETCH limits.
Raise SQLNET.EXPIRE_TIME / keepalive and adjust firewall idle timeouts to survive long-running fetches.
For ORA-01555, reduce query runtime, fetch in smaller batches, or increase undo tablespace/retention.
Verify session stability: check for kill_session events or resource-manager limits if errors recur on long queries.

Example fix

// before: one giant unbounded query
SELECT * FROM huge_table;

// after: batch with FETCH FIRST to keep each fetch window short
SELECT * FROM huge_table ORDER BY id OFFSET :offset ROWS FETCH NEXT :batch ROWS ONLY;

Defensive patterns

Strategy: retry

Validate before calling

ctx, cancel := context.WithTimeout(ctx, 5*time.Minute)
defer cancel()
if err := db.PingContext(ctx); err != nil {
    return fmt.Errorf("connection unhealthy before long fetch: %w", err)
}

Try / catch

out, err := source.RunSQL(ctx, stmt, params, true)
if err != nil {
    if strings.Contains(err.Error(), "errors encountered during query execution") {
        if isTransient(err) { // e.g. network reset, ORA-03113/03135
            time.Sleep(backoff)
            out, err = source.RunSQL(ctx, pagedStmt, params, true) // re-run with FETCH FIRST batching
        }
    }
}
if err != nil { return err }

Prevention

Page large result sets with ORDER BY + FETCH FIRST/OFFSET instead of one unbounded query.
Set SQLNET.EXPIRE_TIME and TCP keepalives for long-running fetches.
Size undo tablespace/retention for your longest queries to avoid ORA-01555.
Use contexts with timeouts slightly above expected query duration; log the wrapped ORA- code for diagnosis.
Keep queries idempotent (read-only) so retry after mid-fetch failure is safe.

When it happens

Trigger: RunSQL (readOnly=true) iterating a large result set when: the connection to Oracle drops mid-fetch (network reset, firewall idle timeout, session killed with ORA-00028), the context is canceled while rows stream, or the server raises an error partway through the cursor (e.g. ORA-01555 snapshot too old, temp/undo exhaustion).

Common situations: Large exports/queries exceeding Oracle undo retention (ORA-01555); result sets too big for one fetch window combined with unstable networks; long queries canceled by client-side context deadlines; DBA-killed sessions during heavy scans.

Related errors

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