What causes "cloud_web: invalid reply context type %T" in chenhg5/cc-connect?

Ensure the reply context passed to a cloud_web platform was produced by that same platform (its replyContext type)

cloud_web: invalid reply context type %T

Error message

cloud_web: invalid reply context type %T

What it means

parseReplyCtx rejects any value that is neither replyContext nor *replyContext. The %T verb prints the actual Go type of the offending value, so the message tells you exactly what was passed where a cloud-web reply context was expected. This guards against mixing reply-context types across platform adapters.

Source

Thrown at platform/cloud-web/cloudweb.go:696

func (p *Platform) sendWire(ctx context.Context, msg map[string]any) error {
	if ctx == nil {
		ctx = context.Background()
	}
	return p.tp.Send(ctx, msg)
}

func parseReplyCtx(v any) (replyContext, error) {
	switch rc := v.(type) {
	case replyContext:
		return rc, nil
	case *replyContext:
		if rc == nil {
			return replyContext{}, fmt.Errorf("cloud_web: nil reply context")
		}
		return *rc, nil
	default:
		return replyContext{}, fmt.Errorf("cloud_web: invalid reply context type %T", v)
	}
}

func firstNonEmpty(values ...string) string {
	for _, v := range values {
		if strings.TrimSpace(v) != "" {
			return v
		}
	}
	return ""
}

View on GitHub (pinned to 4000b2338a)

Solutions

Ensure the reply context passed to a cloud_web platform was produced by that same platform (its replyContext type)
Fix cross-platform wiring so each platform receives its own stored reply context
If wrapping contexts, unwrap to the underlying cloudweb replyContext before calling
Check the %T in the message to identify the wrong type and locate the code producing it

Example fix

// before
p.Reply(ctx, telegramCtx, "hi") // telegramCtx is *telegram.ReplyContext

// after
cwCtx, ok := ctxMap[sessionKey].(cloudweb.ReplyContext)
if !ok {
    return fmt.Errorf("wrong context type for cloud_web")
}
p.Reply(ctx, cwCtx, "hi")

Defensive patterns

Strategy: type-guard

Validate before calling

if _, ok := v.(cloudweb.ReplyContext); !ok {
    return fmt.Errorf("value is not a cloud_web reply context: %T", v)
}

Type guard

func isCloudWebReplyCtx(v any) bool { _, ok := v.(cloudweb.ReplyContext); return ok }

Try / catch

if err := p.Reply(ctx, v, msg); err != nil && strings.Contains(err.Error(), "invalid reply context type") {
    return fmt.Errorf("wrong platform context routed to cloud_web: %w", err)
}

Prevention

Keep reply contexts keyed per platform so each send call receives its own type
Avoid passing raw handles (strings/ints) where the platform expects its context type
After platform refactors, grep send call sites for context type changes

When it happens

Trigger: Passing a reply context obtained from a different platform adapter (e.g. feishu or telegram reply context) into a cloud_web Platform's Reply/SendCard/SendWithButtons/UpdateMessage/DeletePreviewMessage, or passing a string/int handle.

Common situations: Generic engine code storing reply contexts in an any-typed map and routing to the wrong platform's send method; refactors that changed the context type without updating all call sites; tests reusing a fake context struct.

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors

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