hyperledger/fabric · error

message of type %s unknown

Error message

message of type %s unknown

What it means

In `encodeProto` (cmd/configtxlator/main.go:137), the message type was resolved but `reflect.TypeOf(mt.Zero().Interface())` returned nil, so configtxlator cannot construct a concrete Go type for the message. This guard catches registry entries that do not yield a usable reflect.Type (effectively an impossible/unsupported type resolution).

Source

Thrown at cmd/configtxlator/main.go:137

	}

	app.Fatalf("Error starting server:[%s]\n", err)
}

func printVersion() {
	fmt.Println(metadata.GetVersionInfo())
}

func encodeProto(msgName string, input, output *os.File) error {
	mt, err := protoregistry.GlobalTypes.FindMessageByName(protoreflect.FullName(msgName))
	if err != nil {
		return errors.Wrapf(err, "error encode input")
	}

	msgType := reflect.TypeOf(mt.Zero().Interface())

	if msgType == nil {
		return errors.Errorf("message of type %s unknown", msgType)
	}
	msg := reflect.New(msgType.Elem()).Interface().(proto.Message)

	err = protolator.DeepUnmarshalJSON(input, msg)
	if err != nil {
		return errors.Wrapf(err, "error decoding input")
	}

	if msg == nil {
		return errors.New("error marshaling: proto: Marshal called with nil")
	}
	out, err := proto.Marshal(msg)
	if err != nil {
		return errors.Wrapf(err, "error marshaling")
	}

	_, err = output.Write(out)
	if err != nil {

View on GitHub (pinned to 2736b63f8f)

Solutions

  1. Rebuild/download a configtxlator binary that matches your Fabric and fabric-protos version.
  2. Verify with a known-good type first (e.g. --type common.Config) to isolate whether the tool itself is broken.
  3. If building from source, ensure the generated proto Go packages are imported so types are registered.

Example fix

// before: custom-built binary missing proto registrations
$ go build -o configtxlator ./cmd/configtxlator  // pruned imports -> type unknown
// after: import the proto packages (or use official release)
import _ "github.com/hyperledger/fabric-protos-go/common"
Defensive patterns

Strategy: type-guard

Validate before calling

// Sanity-check the tool first
$ configtxlator proto_encode --type common.Config --input valid.json --output /tmp/t.pb || echo "tool broken"

Type guard

mt, err := protoregistry.GlobalTypes.FindMessageByName(protoreflect.FullName(msgName))
if err != nil || mt == nil || reflect.TypeOf(mt.Zero().Interface()) == nil {
	return fmt.Errorf("no usable Go type registered for %q", msgName)
}

Try / catch

out, err := exec.Command("configtxlator", "proto_encode", "--type", msgType, ...).CombinedOutput()
if err != nil && strings.Contains(string(out), "message of type") {
	return fmt.Errorf("configtxlator build lacks type %s; use official release binary", msgType)
}

Prevention

When it happens

Trigger: `configtxlator proto_encode --type <name>` where the registered message yields a nil Go type — practically hit only when the message name resolves in protoregistry but its generated Go type is unavailable (binary/tooling version mismatch).

Common situations: Mismatched fabric/fabric-protos versions in a custom-built configtxlator binary; a plugin-built binary missing generated message types; exotic dynamic message names.

Related errors


AI-assisted analysis of hyperledger/fabric@2736b63f8f (2026-09-04). Data as JSON: /api/errors/5d708ba1cbda7134. Report an issue: GitHub.