t8y2/dbx · warning

failed to identify Xugu server session: found %d new session

Error message

failed to identify Xugu server session: found %d new sessions

What it means

When connecting with a control session, the driver snapshots SYS_SESSIONS before and after connecting to identify which new server session belongs to this logical session. newXuguDatabaseSession fails with 'failed to identify Xugu server session: found %d new sessions' when the diff does not yield exactly one new session (zero, or two or more). Callers treat this as a soft degrade: the connection still works, but cancel/kill targeting of that specific server session is unavailable.

Source

Thrown at agents/drivers/xugu/main.go:1465

	defer rows.Close()
	result := map[xuguDatabaseSession]struct{}{}
	for rows.Next() {
		var session xuguDatabaseSession
		if err := rows.Scan(&session.nodeID, &session.sessionID); err != nil {
			return nil, err
		}
		result[session] = struct{}{}
	}
	return result, rows.Err()
}

func newXuguDatabaseSession(
	before map[xuguDatabaseSession]struct{},
	after map[xuguDatabaseSession]struct{},
) (xuguDatabaseSession, error) {
	session, n, ok := controlSessionFromSnapshot(before, after)
	if !ok {
		return xuguDatabaseSession{}, fmt.Errorf("failed to identify Xugu server session: found %d new sessions", n)
	}
	return session, nil
}

// controlSessionFromSnapshot returns the single newly appeared session, if any.
// Callers treat ok=false as a soft degrade signal (no cancel/kill), not a hard error.
// n is the number of newly appeared sessions (useful for error messages).
func controlSessionFromSnapshot(
	before map[xuguDatabaseSession]struct{},
	after map[xuguDatabaseSession]struct{},
) (xuguDatabaseSession, int, bool) {
	var candidates []xuguDatabaseSession
	for session := range after {
		if _, existed := before[session]; !existed {
			candidates = append(candidates, session)
		}
	}
	if len(candidates) != 1 {

View on GitHub (pinned to c0390bff16)

Solutions

1. Retry the connect during a quieter window so the snapshot diff yields exactly one session.
2. Reduce concurrent connect attempts to this server while using control sessions.
3. Verify the Xugu server version supports APP_NAME-based identification and SYS_SESSIONS filtering; upgrade or disable the marker if not.
4. Accept degraded behavior: the session works, only cancel/kill is unavailable — log and continue.

Example fix

// before
sess, err := newXuguDatabaseSession(before, after) // hard-fails pipelines
if err != nil { return err }
// after
sess, err := newXuguDatabaseSession(before, after)
if err != nil { log.Warn("cancel/kill unavailable: ", err) /* continue degraded */ }

// avoid noisy snapshot windows: defer connect when other clients are opening sessions
if serverBusyWindow() { scheduleConnectLater() }

func isSessionIdentificationError(err error) bool {
  return err != nil && strings.Contains(err.Error(), "failed to identify Xugu server session")
}

if err := connectWithControl(); err != nil {
  if isSessionIdentificationError(err) {
    log.Warn("cancel/kill unavailable; continuing degraded")
    proceedWithoutControl()
  }
}

When it happens

Trigger: Another client connected concurrently between the before/after snapshots (2+ new rows); no new session was visible at all (0 new); the server/driver combination does not support the APP_NAME-based session marking used for identification (some Xugu versions close the socket when APP_NAME is set).

Common situations: Busy production Xugu server where other apps open sessions in the same window; older Xugu server/driver combos incompatible with the APP_NAME marker; monitoring tools polling sessions during connect.

Related errors

• scheduler job name is required
• sequence name is required
• synonym name is required
• sql is required
• cannot reconnect Xugu session without connection parameters

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