chenhg5/cc-connect · error

bridge: adapter does not support reconstruct_reply

Error message

bridge: adapter %q does not support reconstruct_reply

What it means

ReconstructReplyCtx requires the target adapter to declare the 'reconstruct_reply' capability. The adapter is connected, but its capability set lacks this flag, so the bridge cannot rebuild an opaque reply context for it and returns this error.

Solutions

1. Upgrade or patch the adapter implementation to advertise capabilities["reconstruct_reply"] = true and implement the reconstruction protocol.
2. Use a different mechanism for replies with this adapter (e.g. store the original live replyCtx instead of reconstructing).
3. Feature-detect before calling: check the adapter's capabilities yourself and fall back to a plain send.

Example fix

// before
replyCtx, err := bp.ReconstructReplyCtx(sessionKey) // panics into error for simple adapters

// after
if !adapterSupportsReconstruct(sessionKey) {
    return fmt.Errorf("destination does not support context reconstruction")
}
replyCtx, err := bp.ReconstructReplyCtx(sessionKey)

func adapterSupportsReconstruct(a *bridgeAdapter) bool { return a.capabilities["reconstruct_reply"] }

rc, err := bp.ReconstructReplyCtx(key)
if err != nil && strings.Contains(err.Error(), "reconstruct_reply") {
    return errors.New("destination does not support context reconstruction; use live reply instead")
}

When it happens

Trigger: Calling ReconstructReplyCtx against an adapter whose capabilities map has no 'reconstruct_reply' entry — typically a simpler/newer adapter implementation that doesn't support context reconstruction.

Common situations: Custom or third-party bridge adapters written without reconstruct_reply support; version skew where the client-side adapter is older than the bridge server expecting the capability.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• bridge: adapter not connected
• platform does not support proactive messaging
• platform does not support proactive messaging (timer)
• platform does not support ReconstructReplyCtx
• platform

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

Appendix: source

Thrown at core/bridge.go:358

		"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
	}
	rc.Platform = a.platform
	rc.progressStyle = bridgeProgressStyleForAdapter(a)

View on GitHub (pinned to 4000b2338a)