search

OrleansContrib / Orleans.Sagas

A distributed saga implementation for Orleans
MIT License
150 stars 28 forks source link

Infinite growth of state after saga completions #37

Closed highlyunavailable closed 2 years ago

highlyunavailable commented 3 years ago

The saga and completion grains never clean up their state. While history may be valuable for the saga grain itself (though I would argue that the saga should at least have an option to clean itself up), the random bool and associated metadata of the cancellation grain should be cleaned up after the saga has completed for any reason.

creyke commented 3 years ago

To ensure requests to restart an already aborted saga are idempotent, the SagaCompletitionGrain retains state after the saga has completed.

A sweeper service could be used to clean up saga state after a period of inactivity, although making this storage agnostic may be challenging.

Currently this has to be implemented manually, and is dependent on an individual storage provider.

Open to proposals on alternatives.

highlyunavailable commented 3 years ago

Makes sense, but I was wondering why the SagaCompletitionGrain isn't purged after the saga has completed. In fact, I'm curious as to why the SagaCompletitionGrain exists at all, since the SagaGrain should be able to take care of storage. I saw a comment about storage mutation, but that feels like there's a larger problem if the storage of the saga is being mutated by something other than the Saga grain while in-progress.

creyke commented 3 years ago

Sorry for the delay. The completion grain is separate so it can be "always available" for immediate cancellation request persistence, even when the saga grain is active. It's technically possible to do this with reentrancy, but this wasn't the design decision at the time.

I'm open to changing it, it's just a case of understanding how significant the issue with it is currently and finding time to do it / someone PRing the changes.