Protect against nil messages, which happen very infrequently.

[rrh]

The root cause of nil messages has not been diagnosed.

Run "go fmt"

[wvanbergen]

The only explanation I have for nil messages is the channel being closed outside of the consumers control, after which we end up reading zero values from the channel.

What do you think of this:

case messages, ok <- message:
  if ok {
    lastOffset = message.Offset
  else {
    // log something
  }

This would only protect against this particular case instead of nil values actually being present on the channel (which should never happen). Also, maybe we can log something that would allow us to investigate further?

cc @andremedeiros

[rrh]

I'm confused. Your counter proposal is to use:
case messages, ok <- message
but this is a case on a send statement, and AFAICT send statements don't allow for a way to assign "success/failure" to an auxiliary bool.

[rrh]

ping?

Your proposal doesn't compile:
./consumer_group.go:412: select cases cannot be lists

Further, even if the send succeeds (ok == true), it may still succeed with a nil message, and we'll then still redirect through nil causing a NPE.

[rrh]

[[Adding a log message is easy..]]