wavetermdev/waveterm · warning

cannot connect to %q when status is %q

Error message

cannot connect to %q when status is %q

What it means

Connect() refuses to start a connection when the WSLConn's current status is already 'connecting' or 'connected' (the connectAllowed guard around line 494). Returning this error instead of double-connecting protects the connection state machine from concurrent connects.

Source

Thrown at pkg/wslconn/wslconn.go:505

	}
}

// does not return an error since that error is stored inside of WslConn
func (conn *WslConn) Connect(ctx context.Context) error {
	var connectAllowed bool
	conn.WithLock(func() {
		if conn.Status == Status_Connecting || conn.Status == Status_Connected {
			connectAllowed = false
		} else {
			conn.Status = Status_Connecting
			conn.Error = ""
			connectAllowed = true
		}
	})
	log.Printf("Connect %s\n", conn.GetName())
	if !connectAllowed {
		conn.Infof(ctx, "cannot connect to %q when status is %q\n", conn.GetName(), conn.GetStatus())
		return fmt.Errorf("cannot connect to %q when status is %q", conn.GetName(), conn.GetStatus())
	}
	conn.FireConnChangeEvent()
	err := conn.connectInternal(ctx)
	conn.WithLock(func() {
		if err != nil {
			conn.Infof(ctx, "ERROR %v\n\n", err)
			conn.Status = Status_Error
			conn.Error = err.Error()
			conn.close_nolock()
			telemetry.GoUpdateActivityWrap(wshrpc.ActivityUpdate{
				Conn: map[string]int{"wsl:connecterror": 1},
			}, "wsl-connconnect")
			telemetry.GoRecordTEventWrap(&telemetrydata.TEvent{
				Event: "conn:connecterror",
				Props: telemetrydata.TEventProps{
					ConnType: "wsl",
				},
			})

View on GitHub (pinned to a4447c1563)

Solutions

  1. Check conn status (DeriveConnStatus()) before calling Connect and skip if already connecting/connected
  2. Serialize connects through one code path (e.g. EnsureConnection) instead of calling Connect directly
  3. Wait for the in-flight connect to settle (WaitForConnect) before issuing another Connect
  4. If the connection appears connected but is actually dead, call Disconnect/Close first, then Connect

Example fix

// before
err := wslconn.Reconnect(ctx, connName)
// after
status := wslconn.DeriveConnStatusFor(connName)
if status.Status == wslconn.Status_Connected || status.Status == wslconn.Status_Connecting {
    return nil // already connected/connecting
}
err := wslconn.Reconnect(ctx, connName)
Defensive patterns

Strategy: validation

Validate before calling

st := wslconn.DeriveConnStatusFor(connName)
if st != nil && (st.Status == wslconn.Status_Connecting || st.Status == wslconn.Status_Connected) {
    return nil // nothing to do
}
err := wslconn.Reconnect(ctx, connName)

Try / catch

if err := conn.Connect(ctx); err != nil {
    if strings.Contains(err.Error(), "when status is") {
        // already connecting/connected; wait instead of retry
        return conn.WaitForConnect(ctx)
    }
    return err
}

Prevention

When it happens

Trigger: Calling Connect() (directly or via Reconnect()) while conn.GetStatus() is Status_Connecting or Status_Connected — e.g. two callers racing to connect the same connection, or Reconnect() invoked while a prior connect is still in flight.

Common situations: Frontend fires a reconnect action while the initial auto-connect is still running; a block-level 'ensure connected' call races with a user-triggered connect; stale UI shows 'disconnected' while the connection actually re-established.

Related errors


AI-assisted analysis of wavetermdev/waveterm@a4447c1563 (2026-09-01). Data as JSON: /api/errors/24ab354ee7fea1b3. Report an issue: GitHub.