[Issue 664] fix ReconsumeLater panic

[crossoverJie]

Fixes #664

Motivation

Removing possible panic.

Modifications

Add nil check and more friendly tips.

Verifying this change

• Make sure that the change passes the CI checks.

[crossoverJie]

@shoothzj would you mind enabling the workflows and reviewing them?

[shileiyu]

Calling ReconsumeLater without a DLQ policy doesn't make sense in most cases. that sounds some messages could be stuck in an infinite loop forever.

[crossoverJie]

@shileiyu Yes, I agree.

However, there may be careless developers like me who cause the program to run with panic which can even affect the business, this may cut some losses.

[shileiyu]

I’m thinking how could we have a better interface to help developers actively avoiding the pitfall.

[shileiyu]

@crossoverJie do you think having a default DLQ policy would be a better solution to this issue?

[crossoverJie]

@shileiyu It's a good idea.
If RetryEnable==true in the Java SDK, a default policy is created.

[wolfstudy]

@shileiyu It's a good idea. If RetryEnable==true in the Java SDK, a default policy is created.

In Go SDK, we have also made the same settings. When retry is enabled, a default DLQ policy will be created. The essential reason for this panic is that we have not enabled retry, but are trying to use ReconsumeLater

if options.DLQ == nil {
			options.DLQ = &DLQPolicy{
				MaxDeliveries:    MaxReconsumeTimes,
				DeadLetterTopic:  dlqTopic,
				RetryLetterTopic: retryTopic,
			}
		}

[wolfstudy]

LGTM +1