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
- Check conn status (DeriveConnStatus()) before calling Connect and skip if already connecting/connected
- Serialize connects through one code path (e.g. EnsureConnection) instead of calling Connect directly
- Wait for the in-flight connect to settle (WaitForConnect) before issuing another Connect
- 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
- Route all connect requests through EnsureConnection instead of raw Connect
- Debounce UI reconnect buttons
- Track in-flight connect promises per connection
- Check DeriveConnStatus before connecting
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
- connection error: %s
- no webcontents found with blockid ${data.blockid}
- window ${windowId} not found
- encryption is not available
- wsl connection %s not connected, cannot start shellproc
AI-assisted analysis of wavetermdev/waveterm@a4447c1563 (2026-09-01).
Data as JSON: /api/errors/24ab354ee7fea1b3.
Report an issue: GitHub.