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
- Rebuild/download a configtxlator binary that matches your Fabric and fabric-protos version.
- Verify with a known-good type first (e.g. --type common.Config) to isolate whether the tool itself is broken.
- 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
- Download configtxlator from official Fabric releases, not ad-hoc builds.
- When building from source, import all needed fabric-protos-go packages so types register.
- Smoke-test with common.Config before scripting bulk conversions.
- Keep tooling version aligned with fabric-protos version.
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
- error encode input
- error marshaling: proto: Marshal called with nil
- error marshaling
- malformed org definition for org: %s
- error decoding input
AI-assisted analysis of hyperledger/fabric@2736b63f8f (2026-09-04).
Data as JSON: /api/errors/5d708ba1cbda7134.
Report an issue: GitHub.