chenhg5/cc-connect · error

wecom-ws: decode aeskey hex: %w

Error message

wecom-ws: decode aeskey hex: %w

What it means

Wrap of hex.DecodeString inside decodeWeComAESKey's normalization ladder: the input looked like a 64-char hex string (passed the isHexString check) but Go's decoder still rejected it. In practice near-impossible since isHexString pre-validates the alphabet; firing indicates an edge case in the heuristic or corrupted input, after whitespace was already stripped.

Source

Thrown at platform/wecom/websocket_media.go:224

	if s == "" {
		return nil, fmt.Errorf("wecom-ws: empty aeskey")
	}
	var b strings.Builder
	b.Grow(len(s))
	for i := 0; i < len(s); i++ {
		switch s[i] {
		case '\n', '\r', ' ', '\t':
			continue
		default:
			b.WriteByte(s[i])
		}
	}
	s = b.String()

	if len(s) == 64 && isHexString(s) {
		key, err := hex.DecodeString(s)
		if err != nil {
			return nil, fmt.Errorf("wecom-ws: decode aeskey hex: %w", err)
		}
		if len(key) != 32 {
			return nil, fmt.Errorf("wecom-ws: aeskey hex length %d, want 32 bytes", len(key))
		}
		return key, nil
	}

	// URL-safe alphabet → standard (RFC 4648 §5)
	s = strings.ReplaceAll(s, "-", "+")
	s = strings.ReplaceAll(s, "_", "/")

	switch len(s) % 4 {
	case 0:
	case 2:
		s += "=="
	case 3:
		s += "="
	default:

View on GitHub (pinned to 4000b2338a)

Solutions

1. Log the normalized input length and first bytes to see why isHexString and hex.DecodeString disagree
2. If it fires in production, fall through to the Base64 branch instead of hard-failing, since the hex path is only a compatibility guess
3. Add a unit test covering the divergent input to pin the behavior

When it happens

Trigger: Thrown at platform/wecom/websocket_media.go:224 when the library encounters an invalid state.

Common situations: See trigger scenarios.

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