elsa-core: Bug: Elsa 2.0 MongoDb Deserializing

@Juandavi1 This should be fixed with the latest preview packages available on MyGet and of course in master. Please feel free to reopen if you can still reproduce this issue with the latest version and repro steps. Thanks!

Tricky problem, here’s why:

• When using MongoDB, we need to register any and all types that are potentially stored in a workflow instance using BsonClassMap.RegisterClassMap<T>.
• We have many modules with activities that potentially store something within a workflow instance.
• None of these modules should have a dependency on MongoDB.
• The MongoDb provider itself should also not have a dependency on any of the activity modules (such as Elsa.Activities.Http).

One not-so-great solution I can think of is to require the host application to register these types, like so:

public class Startup
{
    public Startup()
    {
        BsonClassMap.RegisterClassMap<HttpRequestModel>(cm => cm.AutoMap());
    }
}

Which is far from ideal of course, because now the user needs to understand what types to register, depending on what activity packages they use.

So what we might do instead is let Newtonsoft.Json take care of object serialization, which does not require “known types” to be registered.

I tried it and it works wonders, but it also means that it will break existing MongoDB databases where they basically need to wipe their DB.

No longer reproducible as-described

Hi @Rafael94 - I’ve been looking into this to try and address it in Elsa 2.0. After some exploration, I’m not sure that this requires any code change for Elsa 2.0 and has been “fixed by accident” during other work on the various models used to persist information in the database.

I’ve got a test-case in Elsa 2.0 which proves that a workflow instance may be persisted and then read-back from MongoDb. That’s a fairly minimal example, but you can see that a workflow may be started, suspended, persisted and then retrieved OK. The property of a WorkflowInstance which is noted in your original issue report: Activities no longer exists, and its replacements/conceptual equivalents store only objects that have primitive properties and which are not polymorphic.

I have also had a look around at some of the other models which are persisted into the data store and they have been refactored in similar ways. If you can create a reproduction case for this in Elsa 2.0 then please share it, but overall I think this one has actually been “fixed for free”.

I’ll leave this issue open for a while, in case anybody finds a reproduction case, but it’s my belief that we don’t need to make any code changes here. If this is still open when Elsa 2.0 is due for release, my recommendation would be to close it.

Two new issues created for those aside-tasks: #650 and #651.