Add configurable ObjectSerializer for MongoDB persistence to allow user type deserialization

[Copilot]

When using MongoDB persistence with user-defined data classes, users encounter a BsonSerializationException:

Type WorkflowCore.Sample04.MyDataClass is not configured as a type that is allowed to be deserialized for this instance of ObjectSerializer.

This occurs when enabling MongoDB persistence in Sample04:

services.AddWorkflow(x => x.UseMongoDB(@"mongodb://localhost:27017", "workflow"));

The issue stems from the DataObjectSerializer.Deserialize method using BsonSerializer.Deserialize(context.Reader, typeof(object)), which relies on MongoDB's global ObjectSerializer. By default, this serializer has security restrictions that prevent deserialization of user types.

Solution

This fix adds a serializerTypeFilter parameter to the UseMongoDB extension methods, allowing users to explicitly configure which types are allowed for serialization/deserialization. This approach makes no assumptions about user namespaces and gives complete control to the developer.

Configuration Example:

services.AddWorkflow(x => x.UseMongoDB(
    @"mongodb://localhost:27017", 
    "workflow",
    serializerTypeFilter: type =>
        ObjectSerializer.DefaultAllowedTypes(type) || 
        type.FullName?.StartsWith("MyApp.") == true));

Multiple Namespaces Example:

services.AddWorkflow(x => x.UseMongoDB(
    @"mongodb://localhost:27017", 
    "workflow",
    serializerTypeFilter: type =>
    {
        if (ObjectSerializer.DefaultAllowedTypes(type))
            return true;
            
        var fullName = type.FullName ?? "";
        return fullName.StartsWith("MyApp.") || 
               fullName.StartsWith("MyCompany.Models.") ||
               fullName.StartsWith("WorkflowCore.");
    }));

Key Benefits

• ✅ No hardcoded assumptions - Users explicitly define which types are allowed
• ✅ Complete flexibility - Works with any namespace structure
• ✅ Security-conscious - Users can include/exclude types as needed
• ✅ Backward compatible - Parameter is optional (though configuration is required to avoid serialization errors)

Documentation

Updated README with comprehensive examples showing how to configure the ObjectSerializer for various scenarios.

Fixes #1372.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[danielgerlag]

@copilot this is only going to work because of the namespace of the samples, that will not be true in a real world use case.

[Copilot]

@copilot this is only going to work because of the namespace of the samples, that will not be true in a real world use case.

You're absolutely right. I've enhanced the fix to support real-world user types beyond just WorkflowCore namespaces.

The updated ObjectSerializer registration now allows:

• Default allowed types (primitives, collections, etc.)
• WorkflowCore types (backward compatibility)
• All user types while blocking System/Microsoft types for security

This works for user namespaces like MyApp.Models.CustomerData or SomeCompany.Workflows.Data.OrderData. Tested successfully with comprehensive scenarios.

Fixed in commit 70e02bb

[danielgerlag]

@copilot we should not make assumptions about namespaces. Remove all the hard coded namespace prefixes, and allow the user to configure what gets registered when they wire up Mongo as a persistence provider.

[Copilot]

@copilot we should not make assumptions about namespaces. Remove all the hard coded namespace prefixes, and allow the user to configure what gets registered when they wire up Mongo as a persistence pr...

Done. Removed all hardcoded namespace checks and added a serializerTypeFilter parameter to UseMongoDB that allows users to configure which types are allowed for serialization.

Users now explicitly configure the ObjectSerializer:

services.AddWorkflow(x => x.UseMongoDB(
    @"mongodb://localhost:27017", 
    "workflow",
    serializerTypeFilter: type =>
        ObjectSerializer.DefaultAllowedTypes(type) || 
        type.FullName?.StartsWith("MyApp.") == true));

Updated README with documentation and examples.

Fixed in commit 724de9f