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

Upgrade/downgrade so both peers share one generated authservice.pb.go (same proto field numbering)

proto: wrong wireType = %d for field BrowserMFARequestID

Error message

proto: wrong wireType = %d for field BrowserMFARequestID

What it means

Generated Unmarshal code expects field 10 (BrowserMFARequestID, a string) to be wire type 2. The incoming bytes use a different wire type for tag 10, so the decoder returns this error and stops. It signals that the payload does not match the compiled message schema.

Source

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

					break
				}
			}
			intStringLen := int(stringLen)
			if intStringLen < 0 {
				return ErrInvalidLengthAuthservice
			}
			postIndex := iNdEx + intStringLen
			if postIndex < 0 {
				return ErrInvalidLengthAuthservice
			}
			if postIndex > l {
				return io.ErrUnexpectedEOF
			}
			m.BrowserMFATSHRedirectURL = string(dAtA[iNdEx:postIndex])
			iNdEx = postIndex
		case 10:
			if wireType != 2 {
				return fmt.Errorf("proto: wrong wireType = %d for field BrowserMFARequestID", 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

Upgrade/downgrade so both peers share one generated authservice.pb.go (same proto field numbering)
Migrate or discard serialized messages persisted under the old schema
Validate the payload with protoc --decode_raw before unmarshaling in custom pipelines
Ensure only proto.Marshal output reaches Unmarshal (no manual byte building)

Example fix

// before: reading old persisted bytes
old, _ := os.ReadFile("mfa_state.bin")
proto.Unmarshal(old, msg)
// after: persist a versioned envelope and re-encode on upgrade
if schemaVer < 2 { old = migrateToV2(old) }
err := proto.Unmarshal(old, msg)

Defensive patterns

Strategy: validation

Validate before calling

func schemaVersion(v int) error {
    if v < currentSchemaVersion {
        return fmt.Errorf("payload schema v%d < required v%d; re-serialize before decode", v, currentSchemaVersion)
    }
    return nil
}

Type guard

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

Try / catch

if err := proto.Unmarshal(stored, &state); err != nil {
    if isWireTypeMismatch(err) {
        stored = migrateStoredState(stored) // re-encode from old schema
        err = proto.Unmarshal(stored, &state)
    }
    if err != nil { return trace.Wrap(err) }
}

Prevention

Version-stamp persisted protobuf state and migrate before decode
Roll schema changes with coordinated upgrades
Never parse in the middle of a buffer; unmarshal from message boundaries
Test decode compatibility between old and new schema versions in CI

When it happens

Trigger: Unmarshaling bytes where field 10 of the MFA-capable message is not length-delimited — commonly after schema evolution renumbered fields, so an old encoder puts different data at tag 10 than the new decoder expects.

Common situations: Rolling upgrades where auth service and clients temporarily disagree on the proto schema; messages persisted before a schema change and re-read after; a non-teleport producer emitting incorrect tags; corrupted frames.

Related errors

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