chenhg5/cc-connect · error

bridge: adapter %q not connected

Error message

bridge: adapter %q not connected

What it means

During ReconstructReplyCtx, the session key resolved to a platform adapter name, but server.getAdapter(platform) returned nil — no adapter with that name is currently connected to the bridge server. The bridge refuses to build a reply context pointing at a disconnected adapter.

Source

Thrown at core/bridge.go:355

		"session_key": rc.SessionKey,
		"reply_ctx":   rc.ReplyCtx,
		"content":     content,
		"format":      "text",
	})
}

func (bp *BridgePlatform) Send(ctx context.Context, replyCtx any, content string) error {
	return bp.Reply(ctx, replyCtx, content)
}

func (bp *BridgePlatform) ReconstructReplyCtx(sessionKey string) (any, error) {
	platform := bp.server.platformFromSessionKey(sessionKey)
	if platform == "" {
		return nil, fmt.Errorf("bridge: cannot determine adapter from session key %q", sessionKey)
	}
	a := bp.server.getAdapter(platform)
	if a == nil {
		return nil, fmt.Errorf("bridge: adapter %q not connected", platform)
	}
	if !a.capabilities["reconstruct_reply"] {
		return nil, fmt.Errorf("bridge: adapter %q does not support reconstruct_reply", platform)
	}
	replyCtx, err := buildBridgeReconstructReplyCtx(bp.project, sessionKey)
	if err != nil {
		return nil, err
	}
	return newBridgeReplyCtx(a, sessionKey, replyCtx), nil
}

func newBridgeReplyCtx(a *bridgeAdapter, sessionKey, replyCtx string) *bridgeReplyCtx {
	rc := &bridgeReplyCtx{
		SessionKey: sessionKey,
		ReplyCtx:   replyCtx,
	}
	if a == nil {
		return rc

View on GitHub (pinned to 4000b2338a)

Solutions

  1. Check that the adapter named in the session key is present in config.toml and not excluded by build tags; restart the bridge.
  2. Verify adapter connectivity (cc-connect doctor / platform logs) and reconnect before replying.
  3. Handle the error in the caller by notifying the user the destination is offline instead of retrying blindly.

Example fix

// before
replyCtx, _ := bp.ReconstructReplyCtx(sessionKey) // adapter may be down
bp.Reply(ctx, replyCtx, msg)

// after
replyCtx, err := bp.ReconstructReplyCtx(sessionKey)
if err != nil {
    slog.Warn("bridge: adapter unavailable", "key", sessionKey, "err", err)
    return err
}
bp.Reply(ctx, replyCtx, msg)
Defensive patterns

Strategy: fallback

Validate before calling

if bp.server.getAdapter(platformFromKey(key)) == nil {
    return errors.New("destination adapter offline; aborting reply")
}

Try / catch

rc, err := bp.ReconstructReplyCtx(key)
if err != nil && strings.Contains(err.Error(), "not connected") {
    slog.Warn("adapter down, deferring reply", "key", key)
    return queueForLater(key)
}

Prevention

When it happens

Trigger: Calling ReconstructReplyCtx after the downstream platform adapter disconnected or was never started; typo'd/renamed adapter in config; bridge server started before the adapter registered.

Common situations: Replying to an old conversation after restarting cc-connect with a platform plugin excluded via build tags (e.g. no_feishu) or removed from config.toml; temporary network disconnect that dropped the adapter.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors


AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06). Data as JSON: /api/errors/1f41c8f478a6449c. Report an issue: GitHub.