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.

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)

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.