What causes "message passed in is nil" in micro/go-micro?

Initialize the message before each Recv: msg := &transport.Message{}; sock.Recv(msg)

message passed in is nil

Error message

message passed in is nil

What it means

httpTransportSocket.Rev — the server-side socket's Recv — requires the caller to supply a non-nil *Message into which the pending request's headers and body are decoded. A nil message leaves no destination for the data, so it returns 'message passed in is nil' without reading the socket.

Source

Thrown at transport/http_socket.go:49

	// local/remote ip
	local  string
	remote string

	mtx sync.RWMutex
}

func (h *httpTransportSocket) Local() string {
	return h.local
}

func (h *httpTransportSocket) Remote() string {
	return h.remote
}

func (h *httpTransportSocket) Recv(msg *Message) error {
	if msg == nil {
		return errors.New("message passed in is nil")
	}

	if msg.Header == nil {
		msg.Header = make(map[string]string, len(h.r.Header))
	}

	if h.r.ProtoMajor == 1 {
		return h.recvHTTP1(msg)
	}

	return h.recvHTTP2(msg)
}

func (h *httpTransportSocket) Send(msg *Message) error {
	// we need to lock to protect the write
	h.mtx.RLock()
	defer h.mtx.RUnlock()

View on GitHub (pinned to 24529f1404)

Solutions

Initialize the message before each Recv: msg := &transport.Message{}; sock.Recv(msg)
Inside a receive loop, allocate a fresh message per iteration instead of reusing a possibly-nil variable
Wrap socket handling so a nil message can never be passed (small helper function that allocates then calls Recv)

Example fix

// before
var msg *transport.Message
sock.Recv(msg) // error
// after
msg := &transport.Message{}
if err := sock.Recv(msg); err != nil { return err }

Defensive patterns

Strategy: validation

Validate before calling

if msg == nil {
	msg = &transport.Message{}
}
err := sock.Recv(msg)

Type guard

func validMessage(m *transport.Message) bool { return m != nil }

Try / catch

if err := sock.Recv(msg); err != nil {
	if strings.Contains(err.Error(), "message passed in is nil") {
		// allocate a fresh message and continue the loop
	}
}

Prevention

Allocate a fresh message inside every handler loop iteration
Wrap socket reads in a helper that guarantees non-nil messages
Don't reset msg to nil on error paths while continuing to Recv

When it happens

Trigger: Server handler code calling sock.Recv(nil), or reusing a *Message variable left nil after a previous loop iteration/error.

Common situations: Handlers copied from client examples where the client allocates the message differently; error paths that set msg back to nil and continue looping on the socket.

Related errors

AI-assisted analysis of micro/go-micro@24529f1404 (2026-09-01). Data as JSON: /api/errors/8a0fd930bf2068c8. Report an issue: GitHub.