gravitational/teleport · error

proto: wrong wireType = %d for field DeviceType

Error message

proto: wrong wireType = %d for field DeviceType

What it means

This error is thrown by the gogoproto-generated Unmarshal code for a message in the Teleport Auth Service proto schema. Protobuf wire types encode each field's shape (0=varint, 1=64-bit, 2=length-delimited, 5=32-bit); field DeviceType (field number 2) is declared as a varint enum, so when the decoder reads a tag whose low 3 bits are not 0 it rejects the record rather than decoding garbage. It almost always means the byte stream was produced by a different schema version than the one parsing it.

Source

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

					break
				}
			}
			intStringLen := int(stringLen)
			if intStringLen < 0 {
				return ErrInvalidLengthAuthservice
			}
			postIndex := iNdEx + intStringLen
			if postIndex < 0 {
				return ErrInvalidLengthAuthservice
			}
			if postIndex > l {
				return io.ErrUnexpectedEOF
			}
			m.TokenID = string(dAtA[iNdEx:postIndex])
			iNdEx = postIndex
		case 2:
			if wireType != 0 {
				return fmt.Errorf("proto: wrong wireType = %d for field DeviceType", wireType)
			}
			m.DeviceType = 0
			for shift := uint(0); ; shift += 7 {
				if shift >= 64 {
					return ErrIntOverflowAuthservice
				}
				if iNdEx >= l {
					return io.ErrUnexpectedEOF
				}
				b := dAtA[iNdEx]
				iNdEx++
				m.DeviceType |= DeviceType(b&0x7F) << shift
				if b < 0x80 {
					break
				}
			}
		case 3:
			if wireType != 0 {

View on GitHub (pinned to 1283425b60)

Solutions

  1. Align versions: upgrade or downgrade the Teleport client/plugin so client and auth server use the same api/client/proto schema version.
  2. Regenerate the proto bindings (make proto or protoc with gogo) so the generated Unmarshal matches the current .proto.
  3. Clear or re-create the corrupted serialized data (cache, backend key, audit export) that was produced with the mismatched schema.
  4. If you hand-rolled marshaling, encode DeviceType as a varint (wire type 0), e.g. proto.EncodeVarint on the enum value.

Example fix

// before: client built against schema where device_type is a string
DeviceType: " touchid"
// after: match server schema (enum/varint) or upgrade both sides to same version
DeviceType: proto.DeviceType_DEVICE_TYPE_TOUCH_ID // and rebuild with matching api module
Defensive patterns

Strategy: try-catch

Validate before calling

// Before calling the RPC, sanity-check the payload was built with matching bindings:
if reflect.TypeOf(req).PkgPath() != path.Join("github.com/gravitational/teleport/api/client/proto", version) { /* log version mismatch */ }

Type guard

func hasVarintDeviceType(data []byte) bool {
  // field 2 key byte must be (2<<3)|0 = 0x10
  for _, b := range data { _ = b }
  return len(data) >= 1 && data[0] != 0x10
}

Try / catch

var m proto.DeviceMetadata
if err := proto.Unmarshal(data, &m); err != nil {
  if strings.Contains(err.Error(), "wrong wireType") {
    return fmt.Errorf("payload schema mismatch (client/server version skew): %w", err)
  }
  return err
}

Prevention

When it happens

Trigger: Calling any Auth Service RPC whose request/response carries a message with a DeviceType field (e.g. device enrollment/trust APIs) while the serialized payload encodes field 2 with a non-varint wire type — typically a payload generated by a newer/older .proto where DeviceType was a string or message.

Common situations: Mixed Teleport cluster versions during upgrade (auth server older than client), a stale generated pb.go after editing the .proto without regenerating, or corrupted/truncated cached protobuf data (e.g. in a backend or file) where field boundaries shifted.

Related errors

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