What causes "proto: wrong wireType = %d for field Name" in thanos-io/thanos?

Build all peers from the same Thanos version so the statuspb schema matches

proto: wrong wireType =

Error message

proto: wrong wireType = %d for field Name

What it means

Generated gogoproto Unmarshal guard for field 1 (Name) of the Statistic message in pkg/status/statuspb/rpc.pb.go:1854. Name is a string and must be length-delimited (wire type 2); the error fires when field 1 arrives with a different wire type, so the wire bytes disagree with the compiled schema.

Solutions

Build all peers from the same Thanos version so the statuspb schema matches
Regenerate pkg/status/statuspb with the protoc/gogoproto toolchain used by the sender
Verify Name is field 1, type string (wire type 2) in the sender's rpc.proto
Capture raw wire data to confirm the sender's encoding if versions already match

Example fix

// before: sender schema diverged
message Statistic { int32 name = 1; }
// after
message Statistic { string name = 1; }

Defensive patterns

Strategy: try-catch

Validate before calling

if !semverCompatible(peerVersion, minSupportedVersion) {
    return fmt.Errorf("peer %s version %s incompatible for TSDB statistics", peer, peerVersion)
}

Try / catch

if err := proto.Unmarshal(buf, &stat); err != nil {
    if strings.Contains(err.Error(), "field Name") {
        return fmt.Errorf("schema mismatch (Name): %w", err)
    }
    return err
}

Prevention

Never change a field's type without a schema-compatibility plan
Round-trip test message encode/decode between builds
Track proto changes in changelogs for operators
Detect peer version skew before making status RPCs

When it happens

Trigger: Unmarshaling a Statistic message where field 1 arrives as varint (0), fixed64 (1), or fixed32 (5) instead of length-delimited (2).

Common situations: Version skew between Thanos components; sender generated from a different rpc.proto where field 1 has a different type; interop with another service reusing the same field numbers with different types.

Understand the failure class

Background: "cannot parse invalid wire-format data", "cannot unmarshal", "failed unmarshalling": protobuf unmarshal errors explained — this error's family across 10 libraries.

Related errors

AI-assisted analysis of thanos-io/thanos@35b8b99117 (2026-09-07). Data as JSON: /api/errors/d9dd4780960a49c8. Report an issue: GitHub.

Appendix: source

Thrown at pkg/status/statuspb/rpc.pb.go:1854

			b := dAtA[iNdEx]
			iNdEx++
			wire |= uint64(b&0x7F) << shift
			if b < 0x80 {
				break
			}
		}
		fieldNum := int32(wire >> 3)
		wireType := int(wire & 0x7)
		if wireType == 4 {
			return fmt.Errorf("proto: Statistic: wiretype end group for non-group")
		}
		if fieldNum <= 0 {
			return fmt.Errorf("proto: Statistic: illegal tag %d (wire type %d)", fieldNum, wire)
		}
		switch fieldNum {
		case 1:
			if wireType != 2 {
				return fmt.Errorf("proto: wrong wireType = %d for field Name", wireType)
			}
			var stringLen uint64
			for shift := uint(0); ; shift += 7 {
				if shift >= 64 {
					return ErrIntOverflowRpc
				}
				if iNdEx >= l {
					return io.ErrUnexpectedEOF
				}
				b := dAtA[iNdEx]
				iNdEx++
				stringLen |= uint64(b&0x7F) << shift
				if b < 0x80 {
					break
				}
			}
			intStringLen := int(stringLen)
			if intStringLen < 0 {

View on GitHub (pinned to 35b8b99117)