Support GuidRepresentationMode v3

[buvinghausen]

With the advent of the 2.11 MongoDB driver they introduced a new GuidRepresentationMode enumeration (which they conveniently marked obsolete as soon as they introduced it as you will see from all the pragma warnings in their code).

Here is their documentation on guid representation. The big takeaway is that V3 will become the default once 3.0 of the driver drops so this needs to be addressed quickly so we can future proof our apps.

Here is their exception

Here is your triggering of the exception

Here is the stacktrace

08:36:59 ERR] Moving message 'e4da69fb-8c2c-4210-9adc-ac3100e064bd' to the error queue 'error' because processing failed due to an exception:
System.InvalidOperationException: This constructor can only be used when BsonDefaults.GuidRepresentationMode is V2.
   at MongoDB.Bson.BsonBinaryData..ctor(Guid guid)
   at MongoDB.Bson.BsonTypeMapper.Convert(Object value, Conversion conversion)
   at MongoDB.Bson.BsonTypeMapper.TryMapToBsonValue(Object value, BsonValue& bsonValue)
   at MongoDB.Bson.BsonTypeMapper.MapToBsonValue(Object value)
   at MongoDB.Bson.BsonValue.Create(Object value)
   at NServiceBus.Storage.MongoDB.SagaPersister.GetSagaData[TSagaData](String elementName, Object elementValue, SynchronizedStorageSession session)
   at NServiceBus.PropertySagaFinder`1.Find(IBuilder builder, SagaFinderDefinition finderDefinition, SynchronizedStorageSession storageSession, ContextBag context, Object message, IReadOnlyDictionary`2 messageHeaders) in /_/src/NServiceBus.Core/Sagas/PropertySagaFinder.cs:line 42
   at NServiceBus.SagaPersistenceBehavior.Invoke(IInvokeHandlerContext context, Func`2 next) in /_/src/NServiceBus.Core/Sagas/SagaPersistenceBehavior.cs:line 78
   at NServiceBus.LoadHandlersConnector.Invoke(IIncomingLogicalMessageContext context, Func`2 stage) in /_/src/NServiceBus.Core/Pipeline/Incoming/LoadHandlersConnector.cs:line 50
   at NServiceBus.ScheduledTaskHandlingBehavior.Invoke(IIncomingLogicalMessageContext context, Func`2 next) in /_/src/NServiceBus.Core/Scheduling/ScheduledTaskHandlingBehavior.cs:line 22
   at NServiceBus.InvokeSagaNotFoundBehavior.Invoke(IIncomingLogicalMessageContext context, Func`2 next) in /_/src/NServiceBus.Core/Sagas/InvokeSagaNotFoundBehavior.cs:line 18
   at NServiceBus.DeserializeMessageConnector.Invoke(IIncomingPhysicalMessageContext context, Func`2 stage) in /_/src/NServiceBus.Core/Pipeline/Incoming/DeserializeMessageConnector.cs:line 33
   at NServiceBus.InvokeAuditPipelineBehavior.Invoke(IIncomingPhysicalMessageContext context, Func`2 next) in /_/src/NServiceBus.Core/Audit/InvokeAuditPipelineBehavior.cs:line 20
   at NServiceBus.ProcessingStatisticsBehavior.Invoke(IIncomingPhysicalMessageContext context, Func`2 next) in /_/src/NServiceBus.Core/Performance/Statistics/ProcessingStatisticsBehavior.cs:line 25
   at NServiceBus.TransportReceiveToPhysicalMessageConnector.Invoke(ITransportReceiveContext context, Func`2 next) in /_/src/NServiceBus.Core/Pipeline/Incoming/TransportReceiveToPhysicalMessageConnector.cs:line 39
   at NServiceBus.MainPipelineExecutor.Invoke(MessageContext messageContext) in /_/src/NServiceBus.Core/Pipeline/MainPipelineExecutor.cs:line 35
   at NServiceBus.LearningTransportMessagePump.ProcessFile(ILearningTransportTransaction transaction, String messageId) in /_/src/NServiceBus.Core/Transports/Learning/LearningTransportMessagePump.cs:line 279

[DavidBoike]

@buvinghausen It appears that the underlying issue is that the MongoDB driver has broken SemVer by introducing a breaking change in a minor version, making NServiceBus.Storage.MongoDB compatible only with MongoDB.Driver versions < 2.11.

Until there's a better solution, the only valid workaround is to stick with 2.10.x of the driver.

Correct?

[buvinghausen]

@DavidBoike technically they didn't because you have to explicitly opt-in to using the V3 mode it doesn't do it by default so this library still works with 2.11.x releases.

I was just trying to give you a heads up that this won't work with the 3.x version of the driver and you can simulate the 3.x behavior and get out ahead of the changes now rather than waiting for the 3.x driver to get released to start.

[DavidBoike]

Ok, so in that case it's not a bug. Our dependency is already on MongoDB.Driver < 3.0 so it not working with that is not (yet) an issue.

I'll raise it with the appropriate group. It won't qualify for immediate prioritization but will more likely get included in some future enhancement release.

Thanks for the report @buvinghausen!

[buvinghausen]

Thanks @DavidBoike

[buvinghausen]

@DavidBoike I saw @timbussmann's spike to fix this is this safe to assume that will make it into the upcoming v3 release?

[DavidBoike]

Hey @buvinghausen - that spike was done as a short analysis Tim did to see how big the problem is, and the discovery was that it's not a "quick fix". There are some issues especially with how to deal with Guids in sagas, i.e. if you have a saga that inherits ContainSagaData you have the Id property as a guid, but the MongoDB storage doesn't have direct access to that code. So there's a lot of testing that's going to need to happen by a dedicated task force to make sure we maintain backward compatibility and stuff like that.

@timbussmann can correct me if I got anything wrong there.

In any case, that work has not been prioritized yet. The focus of the V3 release of this component will be compatibility with NServiceBus version 8 when it's ready, and there's no firm date for that. I'm honestly not sure whether a new V2 minor will be released before NServiceBus 8, or if NServiceBus 8 will be released first and then this would go into MongoDB 3.1 or something like that.