Retry related MT ArgumentException

[Wayne Brantley]

Have an endpoint setup with simple retry:

    sbc.UseRetry(Retry.Intervals(new TimeSpan(0,0,10), new TimeSpan(0,0,10)));

Am getting the exception below.

2015-11-23 13:33:57.068 -05:00 [Error] Rescuing exception

System.ArgumentException: The tasks argument included a null value.

Parameter name: tasks

   at System.Threading.Tasks.Task.WhenAll(IEnumerable`1 tasks)

   at MassTransit.Context.BaseReceiveContext.get_CompleteTask()

   at MassTransit.Serialization.JsonConsumeContext.get_CompleteTask()

   at MassTransit.Pipeline.Filters.DeserializeFilter.<Send>d__4.MoveNext()

--- End of stack trace from previous location where exception was thrown ---

   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

   at MassTransit.Pipeline.Filters.RescueReceiveContextFilter`1.<MassTransit-Pipeline-IFilter<MassTransit-ReceiveContext>-Send>d__5.MoveNext()

The consumer is successfully processing messages.  However, there have be several (6) messages today that ended up in the _error queue.  

The exception that shows is the above one.   

I am running MT version: 3.0.15.258

Questions other than the obvious - why is the above failing...

 - if a message 'fails' and I have a retry policy setup, will the exception (reason for failure) be logged by MT?   In the above, the only exception I received was what you see above.

- if a message goes into the error queue - can we use rabbit shovel to put it back into the regular queue to retry processing as is?  (just not sure if all the headers and exception and such are an issue).   

-  Assuming we can shovel from error to the consumer - I am guessing all the exception information will be lost, so that if it ends back up in the error queue again, we will not have the previous failure also in the message?

[Wayne Brantley]

Chris, 

   Any ideas on this exception inside MT?   We are getting this each day.

[Chris Patterson]

Without knowing what your consumer is doing, it's hard to say for sure. Are you returning an null Task anywhere in your consumer code? That seems to be the most obvious issue from what I see here. Does it matter which retry policy you use (intervals, vs. Interval(2, 10 seconds)? The retry components don't add Tasks to WhenAll, so I can't see where that would do anything. This is waiting for all the pending tasks to complete that were performed during the consumer execution.

The exception should only be logged if the retry policy expires and ultimately throws the exception back up the stack. That would also result in a Fault<T> being published.

Yes, use RabbitMQ to shovel it back into the queue yourself. The header properties will remain when shoveled. If the message fails again, the new error headers will replace the previous ones.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/d909fb01-aa64-4641-80de-08f82bf64597%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Wayne Brantley]

Well, there is nothing special going on.  consumer looks like this:

        public async Task Consume(ConsumeContext<IDocumentAdd> context)

        {

            await _commandQueryProcessor.Process(new DocumentAddCommand

            {

                DocumentId = context.Message.DocumentId

            });

        }

the command is async Task<bool> and returns true/false.

Again, most messages are processed....I do think it is related to some issue with the retry.  We have not tried a different retry policy - but I think it is related to that.   We never return null tasks.   I will investigate the different retry policies...but as I said it works _most_ of the time...

>>The exception should only be logged if the retry policy expires and ultimately throws the exception back up the stack.

I would potentially like to log that exception to see why there are failures at all.  Perhaps I will later disable logging of that, but right now the reason for the rety is completely hidden from me.   Or maybe log it as _debug type?  I would like to investigate and see if there was something we can do to avoid the failure to start with.   And then of course - the actual exception that is published is the one above...not the actual exception.  

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

[Wayne Brantley]

Reproduced the issue.

https://github.com/MassTransit/MassTransit/issues/405

[Chris Patterson]

Found and fixed. 

__
Chris Patterson

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/06bf621e-9262-41e7-be68-33f68b314b0b%40googlegroups.com.