Keeps creating new Saga for every messages after first MarkAsComplete if ContextPreservation Ninject package not being loaded

So, here are basics details about the packages that we are using.

1.package id=“Castle.Core” version=“4.2.0” targetFramework=“net462”
package id=“log4net” version=“2.0.8” targetFramework=“net462”
package id=“Newtonsoft.Json” version=“11.0.2” targetFramework=“net472”
package id=“Ninject” version=“3.3.4” targetFramework=“net472”
package id=“Ninject.Extensions.ContextPreservation” version=“3.3.1” targetFramework=“net472”
package id=“Ninject.Extensions.Factory” version=“3.3.2” targetFramework=“net472”
package id=“Ninject.Extensions.NamedScope” version=“3.3.0” targetFramework=“net462”
package id=“NServiceBus” version=“7.1.4” targetFramework=“net472”
package id=“NServiceBus.Host” version=“8.0.0” targetFramework=“net462”
package id=“NServiceBus.Interfaces” version=“4.6.3” targetFramework=“net45”
package id=“NServiceBus.Persistence.Sql” version=“4.2.0” targetFramework=“net472”
package id=“NServiceBus.Persistence.Sql.MsBuild” version=“4.2.0” targetFramework=“net472” developmentDependency=“true”
<package id=“System.Data.SqlClient” version=“4.4.3” targetFramework=“net472”

One of the linesin end point configuration -

config.UseContainer(c => c.ExistingKernel(IoC.StandardKernel));

What we found out that when we remove Ninject.Extensions.ContextPreservation package it works fine for the first time and then it create a new Saga for every message coming in.

There is no error or any kind of exception. When We add this package, it works as usual. If that is needed when we are using Ninject with NServiceBus, there should be some error or exception being thrown.

Sample code how the Sagas have been written - please refer - [Saga-NServiceBus/TestSaga.cs at master · amitsbaghel/Saga-NServiceBus · GitHub](http://saga code)

I do not understand how this package change the behavior of the Sagas.

I can confirm that Ninject.Extensions.ContextPreservation is needed for NServiceBus to work properly with Ninject. Removing it might as you have seen break things like sagas. Can you elaborate on why you want to remove the reference to it?

1 Like

Thanks for replying, Andrea Sohlund. What happened was we were migrating to NServiceBus 7 and in between that package somehow got removed. After that how Sagas behaved ?
If there is a batch limit set to 5, it will process 5 messages as usual and MarkAsComplete will be called and then rest of the time, every message will keep creating new Sagas.

We could not understand this behavior for so long and eventually got to know that missing ContextPreservation package is causing this weird problem. We added that later.

Why there is no documentation or anything like that these packages should be installed right before using Sagas.?

Or we were then curious to know what causes it to behave Sagas in this way when ContextPreservation package is missing? Is it like the first instance never get disposed? or like what? or it is dependent on the behavior of Ninject?

It would be great if you can spare some time to reply these questions.

Thanks

Why there is no documentation or anything like that these packages should be installed right before using Sagas.?

Just to clarify, the package is needed for the Ninject integration to work in general and not just for sagas.

Regarding documentation, the NuGet package is depending on the context preservation extension (https://www.nuget.org/packages/NServiceBus.Ninject/ see the dependencies section) so we usually consider that enough documentation. Does that make sense?

Both the versions targeting NServiceBus v5 and v6 also depends on that package so something must have gone wrong when you upgraded the project? (Did you get any errors/warnings from NuGet?)

Or we were then curious to know what causes it to behave Sagas in this way when ContextPreservation package is missing? Is it like the first instance never get disposed? or like what? or it is dependent on the behaviour of Ninject?

I would have to do some digging but I have a hunch that this causes incorrect lifetimes for instances registered in the DI container that in some way causes this behaviour.