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 rcView on GitHub (pinned to 4000b2338a)
Solutions
- Check that the adapter named in the session key is present in config.toml and not excluded by build tags; restart the bridge.
- Verify adapter connectivity (cc-connect doctor / platform logs) and reconnect before replying.
- 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
- Run cc-connect doctor to confirm all configured adapters are connected before processing backlogs.
- Avoid excluding adapters via build tags that your stored session keys depend on.
- Monitor adapter disconnects and re-queue outbound messages.
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
- bridge: adapter %q does not support reconstruct_reply
- listen for Agy permission hooks: %w
- generate permission bridge token: %w
- resolve home directory for Agy permission bridge: %w
- create Agy permission overlay: %w
AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06).
Data as JSON: /api/errors/1f41c8f478a6449c.
Report an issue: GitHub.