Is your request related to a problem you have?
Please let me know if this discussed somewhere 馃檪
It appears that a consumer configuration similar to the following is not supported:
middlewareConfiguration
.RetryForever((retryDefinition) =>
retryDefinition
.HandleAnyException()
.WithTimeBetweenTriesPlan(
TimeSpan.FromSeconds(10)
)
);
middlewareConfiguration
.AddTypedHandlers(handlerConfiguration => handlerConfiguration
.WithHandlerLifetime(InstanceLifetime.Transient) // <----------------------------------------
.AddHandlersFromAssemblyOf(assembly.DefinedTypes.First())
);Specifically, non-singleton values of InstanceLifetime do not imply that a new handler is created when an exception is thrown (deep) inside a handler and it bubbles up all the way to Polly. I can observe this by altering a handler dependency (i.e. setting a property value), watching the retry occur, and then inspecting that altered property.
This tends to cause a problem with disposed DB connections 馃槄
Describe the solution you'd like
Does this make sense? Is there a workaround? Should I try to minimally reproduce in case something else is going on?
Ideally the retry middleware would be placed in a way that creates the handler again as if it was a new incoming message.
Are you able to help bring it to life and contribute with a Pull Request?
No
Additional context
It may not be possible to do this with middlewares based on the implementation of https://github.com/Farfetch/kafkaflow/blob/master/src/KafkaFlow/MiddlewareExecutor.cs
Is your request related to a problem you have?
Please let me know if this discussed somewhere 馃檪
It appears that a consumer configuration similar to the following is not supported:
Specifically, non-singleton values of
InstanceLifetimedo not imply that a new handler is created when an exception is thrown (deep) inside a handler and it bubbles up all the way to Polly. I can observe this by altering a handler dependency (i.e. setting a property value), watching the retry occur, and then inspecting that altered property.This tends to cause a problem with disposed DB connections 馃槄
Describe the solution you'd like
Does this make sense? Is there a workaround? Should I try to minimally reproduce in case something else is going on?
Ideally the retry middleware would be placed in a way that creates the handler again as if it was a new incoming message.
Are you able to help bring it to life and contribute with a Pull Request?
No
Additional context
It may not be possible to do this with middlewares based on the implementation of https://github.com/Farfetch/kafkaflow/blob/master/src/KafkaFlow/MiddlewareExecutor.cs