What causes "proto: wrong wireType = %d for field ProxyAddress" in gravitational/teleport?

Align the proto schema/generated code versions between sender and receiver (upgrade the older binary)

proto: wrong wireType = %d for field ProxyAddress

Error message

proto: wrong wireType = %d for field ProxyAddress

What it means

Generated gogoproto Unmarshal code requires field 8 (ProxyAddress, a string) to be length-delimited (wire type 2). The encoded payload presents a different wire type for that field number, so decoding aborts with this error. This guards against decoding bytes produced by a different schema version or corrupt data.

Source

Thrown at api/client/proto/authservice.pb.go:60279

					break
				}
			}
			intStringLen := int(stringLen)
			if intStringLen < 0 {
				return ErrInvalidLengthAuthservice
			}
			postIndex := iNdEx + intStringLen
			if postIndex < 0 {
				return ErrInvalidLengthAuthservice
			}
			if postIndex > l {
				return io.ErrUnexpectedEOF
			}
			m.SSOClientRedirectURL = string(dAtA[iNdEx:postIndex])
			iNdEx = postIndex
		case 8:
			if wireType != 2 {
				return fmt.Errorf("proto: wrong wireType = %d for field ProxyAddress", wireType)
			}
			var stringLen uint64
			for shift := uint(0); ; shift += 7 {
				if shift >= 64 {
					return ErrIntOverflowAuthservice
				}
				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 1283425b60)

Solutions

Align the proto schema/generated code versions between sender and receiver (upgrade the older binary)
Re-serialize the message with the current api/client/proto definitions instead of replaying stale bytes
Decode the payload with protoc --decode_raw to check which wire type field 8 actually uses
Rule out corruption by verifying checksums/TLS termination points that could truncate frames

Example fix

// before: stale cached message bytes from an older schema
blob := cache.Load("proxy_req.bin")
// after: re-marshal from the live struct with current generated code
blob, err := proto.Marshal(req)
if err != nil { return trace.Wrap(err) }
err = proto.Unmarshal(blob, out)

Defensive patterns

Strategy: validation

Validate before calling

func validatePayloadBoundary(b []byte) error {
    if len(b) == 0 { return errors.New("empty payload") }
    if bytes.Equal(b, make([]byte, len(b))) { return errors.New("all-zero payload") }
    return nil
}
// run validatePayloadBoundary(blob) before proto.Unmarshal

Type guard

func isWireTypeError(err error) bool {
    return err != nil && strings.Contains(err.Error(), "wrong wireType = ")
}

Try / catch

if err := proto.Unmarshal(blob, msg); err != nil {
    if isWireTypeError(err) {
        log.WithError(err).Warn("schema mismatch on ProxyAddress field; requesting re-sync")
        return trace.BadParameter("incompatible payload schema")
    }
    return trace.Wrap(err)
}

Prevention

Keep sender and receiver on the same generated proto schema version
Re-marshal stale persisted messages instead of replaying old bytes
Inspect payloads with protoc --decode_raw when versions change
Avoid middlewares that rewrite or truncate binary frames

When it happens

Trigger: Unmarshal is handed bytes where tag 8 of the message carrying ProxyAddress uses wire type != 2 (e.g. a varint or fixed-width encoding), typically during a gRPC call whose request/response includes ProxyAddress.

Common situations: Version skew between teleport client and auth server (field renumbering after schema changes); a third-party client encoding ProxyAddress as another type; corrupted bytes over an unreliable transport; replaying old serialized messages against a newer binary.

Related errors

AI-assisted analysis of gravitational/teleport@1283425b60 (2026-09-02). Data as JSON: /api/errors/ef96c5e5baaf39a0. Report an issue: GitHub.