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

Pass the exact replyContext value the engine gave you with the inbound message; never construct one manually

wecom: invalid reply context type %T

Error message

wecom: invalid reply context type %T

What it means

Reply() expects the reply context argument to be the platform's internal replyContext struct, which carries the userID needed to address the message. Passing anything else (nil, a string, another platform's context type) makes the type assertion fail and returns this error naming the actual dynamic type.

Solutions

Pass the exact replyContext value the engine gave you with the inbound message; never construct one manually
Check you are not mixing reply contexts between platform adapters (each is a distinct Go type)
If you only have a user ID and need to send proactively, use the platform's Send path rather than Reply
Update stale callers after refactors of the replyContext type

Example fix

// before
err := p.Reply(ctx, "user123", "hi") // wrong type
// after
err := p.Reply(ctx, msg.ReplyContext(), "hi") // the replyContext from the inbound message

Defensive patterns

Strategy: type-guard

Type guard

func asWecomReplyContext(rctx any) (wecomReplyContext, bool) {
	rc, ok := rctx.(replyContext)
	return rc, ok
}

Try / catch

rc, ok := rctx.(replyContext)
if !ok {
	return fmt.Errorf("cannot reply: expected wecom replyContext, got %T", rctx)
}

Prevention

Always thread the reply context from the engine's inbound message through to Reply()
Never construct reply contexts by hand or share them across platform adapters
Add a compile-time note/interface where your middleware carries reply contexts

When it happens

Trigger: Calling p.Reply(ctx, rctx, content) with a rctx that was not produced by this wecom platform's message handling — e.g. nil, a string chat ID, or a reply context from a different platform adapter.

Common situations: Bridging messages across platforms and forwarding another platform's reply context; custom automation code inventing a context instead of using the one delivered with the inbound message; a refactor that changed replyContext's type/shape while old callers still pass the old value.

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/09ba135141f5c8e0. Report an issue: GitHub.

Appendix: source

Thrown at platform/wecom/wecom.go:455

					Data:     fileData,
					FileName: baseName,
				}},
				ReplyCtx: rctx,
			})
		}()

	default:
		slog.Warn("wecom: unsupported inbound message type (no handler)",
			"msg_type", msg.MsgType,
			"msg_id", msg.MsgId,
			"from_user", msg.FromUserName)
	}
}

func (p *Platform) Reply(ctx context.Context, rctx any, content string) error {
	rc, ok := rctx.(replyContext)
	if !ok {
		return fmt.Errorf("wecom: invalid reply context type %T", rctx)
	}
	if content == "" {
		return nil
	}

	accessToken, err := p.getAccessToken()
	if err != nil {
		slog.Error("wecom: get access_token failed", "error", err)
		return fmt.Errorf("wecom: get access_token: %w", err)
	}

	if !p.enableMarkdown {
		content = core.StripMarkdown(content)
	}

	chunks := splitByBytes(content, 2000)
	for i, chunk := range chunks {
		var sendErr error

View on GitHub (pinned to 4000b2338a)