At RackTop, we encountered a panic in the req code:

[signal SIGSEGV: segmentation violation code=0x1 addr=0x78 pc=0x96bb85]

goroutine 958498 [running]:
go.nanomsg.org/mangos/v3.(*Message).Clone(...)
go.nanomsg.org/mangos/v3@v3.3.0/message.go:129
go.nanomsg.org/mangos/v3/protocol/req.(*socket).send(0xc000900600)
go.nanomsg.org/mangos/v3@v3.3.0/protocol/req/req.go:90 +0x165
go.nanomsg.org/mangos/v3/protocol/req.(*context).resendMessage(0xc0038483f0, 0x9ba726b0)
go.nanomsg.org/mangos/v3@v3.3.0/protocol/req/req.go:185 +0x13c
go.nanomsg.org/mangos/v3/protocol/req.(*socket).send.func1()
go.nanomsg.org/mangos/v3@v3.3.0/protocol/req/req.go:99 +0x31
created by time.goFunc
time/sleep.go:180 +0x45
[ Jul 22 18:36:48 Stopping because all processes in service exited. ]

What is happening appears to be that for whatever reason by the time we wind up calling s.send(), the message is no longer set on the context, but the context is still in the sendq. Quite possibly this is linked to cancellation.

Anyway if m turns out to be nil, we should just continue the loop and skip the context.