Nil context field on message

[elffjs]

While testing out taskq together with Redis, we found that our applications would panic, usually after a task failure, on a nil pointer dereference here in go-redis:

func (p *ConnPool) waitTurn(ctx context.Context) error {
	select {
	case <-ctx.Done():

Evidently, ctx was nil. The traces were somewhat obscured in cluster mode because of the additional goroutines, but in non-cluster mode we saw this section:

github.com/go-redis/redis/v8.(*Pipeline).Exec(0xc0008eb4d0?, {0x0?, 0x0?})
    /go/src/…/vendor/github.com/go-redis/redis/v8/pipeline.go:125 +0x15f
github.com/vmihailenco/taskq/v3/redisq.(*Queue).Release(0xc0008eb4d0, 0xc000660d00)
    /go/src/…/vendor/github.com/vmihailenco/taskq/v3/redisq/queue.go:245 +0x1ae
github.com/vmihailenco/taskq/v3.(*Consumer).fetchMessages(0xc00002c270, {0x1f41030, 0xc000044090}, 0xc0006b26e0, 0x2?)
    /go/src/…/vendor/github.com/vmihailenco/taskq/v3/consumer.go:439 +0x29f

It seems that msg.Ctx is nil here:

taskq/redisq/queue.go

Line 245 in 8faa953

_, err = pipe.Exec(msg.Ctx)

Indeed, msg is not touched much after msgpack creates it. Looking at a similar part of queue.go we see an explicit initialization of the Ctx field:

taskq/redisq/queue.go

Lines 408 to 410 in 8faa953

	msg := new(taskq.Message)
	msg.Ctx = ctx
	err = unmarshalMessage(msg, xmsg)

Which was added in response to a nil pointer in #150. Adding a similar initialization seems to work here as well.