t8y2/dbx · error

xugu operation timed out

Error message

xugu operation timed out

What it means

errXuguOperationTimeout is a sentinel error (errors.New) returned by classifyRPCError and wrapped into the final error when an Xugu driver RPC exceeds its configured timeout. It signals the operation did not complete in time; the wrapped text includes the timeout in seconds and, when available, the underlying driver error. It uses %w so callers can match with errors.Is.

Source

Thrown at agents/drivers/xugu/protocol_error.go:19

package main

import (
	"context"
	"database/sql"
	"database/sql/driver"
	"errors"
	"fmt"
	"io"
	"net"
	"regexp"
	"strconv"
	"strings"
)

var (
	errAgentSessionLimit     = errors.New("agent session limit reached")
	errAgentSessionNotFound  = errors.New("agent session not found")
	errXuguOperationTimeout  = errors.New("xugu operation timed out")
	errXuguOperationCanceled = errors.New("xugu operation canceled")

	// go-xugu-driver exposes server errors as plain strings rather than a typed
	// error. Match only the stable server error header and keep the complete
	// original message for diagnostics. A response can contain more than one
	// Xugu error; vendorCode intentionally records the first/top-level code.
	xuguServerErrorHeader = regexp.MustCompile(`(?im)^[\t ]*(?:error:[\t ]*)?\[[\t ]*E([0-9]{1,9})(?:[\t ]+L([0-9]+))?(?:[\t ]+C([0-9]+))?[\t ]*\]`)
	xuguQueryTimeout      = regexp.MustCompile(`(?i)^query timed out after [1-9][0-9]*s$`)
)

type rpcError struct {
	Code    int           `json:"code"`
	Message string        `json:"message"`
	Data    *rpcErrorData `json:"data,omitempty"`
}

type rpcErrorData struct {
	Category           string `json:"category"`

View on GitHub (pinned to c0390bff16)

Solutions

1. Increase the configured Xugu timeout (timeout_secs) to cover the slowest expected query
2. Check network latency/stability between client and Xugu server and re-run
3. Profile and optimize the offending query (indexes, filters, smaller result sets)
4. Inspect the wrapped operationErr for a server-side cause (locks, load) and address it
5. Add retry logic with backoff for idempotent read operations

Example fix

// before
result, err := conn.Query(ctx, longQuery) // times out after default 30s
// after
cfg.TimeoutSecs = 300 // raise timeout for heavy analytical queries
result, err := conn.Query(ctx, longQuery)
if errors.Is(err, errXuguOperationTimeout) { /* handle */ }

// Go: pre-check the configured timeout before issuing slow queries
if cfg.TimeoutSecs < estimatedMaxQuerySeconds {
    cfg.TimeoutSecs = estimatedMaxQuerySeconds
}

func IsXuguOperationTimeout(err error) bool {
    return errors.Is(err, errXuguOperationTimeout)
}

result, err := conn.Query(ctx, q)
if errors.Is(err, errXuguOperationTimeout) {
    // increase timeout / retry or surface a timeout-specific message
    return fmt.Errorf("query exceeded %v: %w", cfg.TimeoutSecs, err)
}

When it happens

Trigger: classifyRPCError sets timedOut for a driver RPC (query/execute) and main.go:4320-4322 returns fmt.Errorf("%w after %ds...", errXuguOperationTimeout, timeoutSecs, ...) — i.e. any Xugu operation whose elapsed time exceeded the configured timeout_secs, with or without an accompanying operationErr.

Common situations: Long-running queries on large tables, network latency or packet loss to the Xugu server, server under load, a timeout_secs configured too low for the workload, blocked locks on server-side objects.

Understand the failure class

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• %w after %ds: %v
• %w after %ds
• IoTDB is not reachable at {host}:{port}
• ZooKeeper connection timed out before a session was establis
• ETCD_HISTORY_TIMEOUT

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