Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Impossible to fetch jobs when using conventions on discriminator #328

Closed
uselessChiP opened this issue Nov 14, 2022 · 7 comments
Closed

Comments

@uselessChiP
Copy link

Hi,
I have an external library that sets this kind of convention:

classMap.SetDiscriminator(classMap.ClassType.FullName);

in Hangfire.Mongo, MongoWriteOnlyTransaction -> CreateExpiredJob, jobDto.ToBsonDocument() is called and that makes it so that the types for the job are serialized using the fully qualified name:

{ ... "_t": [ "Hangfire.Mongo.Dto.BaseJobDto", "Hangfire.Mongo.Dto.ExpiringJobDto", "Hangfire.Mongo.Dto.JobDto" ], ... }

The problem is that most of the other code in MongoWriteOnlyTransaction writes "_t" as follows:

["_t"] = new BsonArray {nameof(BaseJobDto), nameof(ExpiringJobDto), nameof(KeyJobDto), nameof(CounterDto)},

making the stored data have different kind of values:

image

Other than that, the BsonDiscriminator is also set as the nameof of the class:

[BsonDiscriminator(nameof(SetDto))]

In this configuration my project isn't working because I guess that OfType is using the discriminator convention that I've mentioned in the beginning and so it doesn't find any set.

I think that the writer class should be updated to serialize all the discriminators based on the conventions.

@gottscj
Copy link
Owner

gottscj commented Nov 20, 2022

@uselessChiP,

Thank you for submitting this. I will look into a solution.

@gottscj
Copy link
Owner

gottscj commented Nov 21, 2022

@uselessChiP,

Kindly try adding this configuration to your codebase:

ConventionRegistry.Register(
               "Hangfire Mongo Conventions",
               new ConventionPack
            {
                new DelegateClassMapConvention("Set Hangfire Mongo Discriminator", cm => 
                cm.SetDiscriminator(cm.ClassType.Name))
            },
               t => t.FullName.StartsWith("Hangfire.Mongo.Dto"));

@uselessChiP
Copy link
Author

uselessChiP commented Nov 22, 2022

Just to give you some feedback.
Your configuration worked but I had to change the DelegateClassMapConvention to a DelegatePostProcessingConvention, since the first convention is registered in post processing (so later than the class maps) and second I had to make sure that this convention was registered somewhere that is called after the initialization of the library containing the FullName discriminator convention.

So it seems to work but it feels like a workaround at the moment.

@gottscj
Copy link
Owner

gottscj commented Nov 22, 2022

@uselessChiP,

Thank you for your feedback. Would initialization be easier if this was embedded in the Hangfire Mongo bootstrapper code? The challenge is that to comply to the "WriteOnlyTransaction" API defined in the Hangfire.Core lib I have to work directly on BsonDocuments. Hangfire.Mongo also needs the "HierarchicalDiscriminatorConvention" as other parts of the code.

I will look into making this library more resilient against other serializer conventions

gottscj added a commit that referenced this issue Nov 26, 2022
use manual serialization. this avoids conflict with serializer conventions

#328
gottscj added a commit that referenced this issue Nov 27, 2022
* use manual serialization

use manual serialization. this avoids conflict with serializer conventions

#328

* remove not used convention

* minor optimization of type casting
@gottscj
Copy link
Owner

gottscj commented Nov 27, 2022

@uselessChiP,

Our conversation triggered a minor re-write. Im now manually serializing the DTO's which should make it immune to any convention there might be used.

Thanks for your input

@gottscj
Copy link
Owner

gottscj commented Jan 22, 2023

@uselessChiP,

Please let me know if your issue has been resolved. Then I'll close this issue.

Thanks!

@gottscj
Copy link
Owner

gottscj commented Jun 23, 2023

closing due to inactivity

@gottscj gottscj closed this as completed Jun 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants