Allow configuration for FailureInfoStorage

[RolandKoenig]

Describe the suggested improvement

Is your improvement related to a problem? Please describe.

We encountered the problem that FailureInfoStorage collected a huge amount of DbUpdateExceptions as a result of a database outage (not the NServiceBus database). The problem on this case is:

• DbUpdateException holds a reference to the originating DbContext (we are using EntityFramework Core)
• FailureInfoStorage collects up to 10000 exceptions (10000 is a hardcoded value, see SqlServerTransportInfrastructure.SelectProcessStrategy)

Describe the suggested solution

I can imagine a few ways to solve this

• Allow to configure maximum entries in FailureInfoStorage (10000 as default are far to many for this situation)
• Allow to manipulate how exceptions are stored (do we even need those exception objects?)

Describe alternatives you've considered

The only alternative way I have in mind is to wrap all message handlers and catch DbUpdateExceptions there and throw a CustomException instead. I would consider that as workaround

Additional Context

No response

[tmasternak]

Hi @RolandKoenig, thank you for your suggestions. We will consider then when doing the next round of platform enhancements.

[RolandKoenig]

In the meanwhile we found the article at: https://docs.particular.net/nservicebus/recoverability/lru-memory-consumption
We will implement a workaround using that solution

Nevertheless this seems to be no clean way in our case. There is no possibility to strip down a DbUpdateException from EF Core (the huge objects there are read only). Maybe there would also be another we If one able to map an exception in some other error model