Skip to content

CSHARP-5633: BsonSerializer.IsTypeDiscriminated is not thread-safe #1722

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.

Sign up for GitHub

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

Merged
merged 3 commits into from
Jul 16, 2025
Merged

CSHARP-5633: BsonSerializer.IsTypeDiscriminated is not thread-safe #1722

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
bb0c10d
CSHARP-5633: BsonSerializer.IsTypeDiscriminated is not thread-safe
papafe Jul 10, 2025
17d1324
Small fix
papafe Jul 14, 2025
ea36b32
Small corrections
papafe Jul 15, 2025
File filter

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions src/MongoDB.Bson/Serialization/BsonSerializer.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,7 @@ public static class BsonSerializer
private static Dictionary<Type, IIdGenerator> __idGenerators = new Dictionary<Type, IIdGenerator>();
private static Dictionary<Type, IDiscriminatorConvention> __discriminatorConventions = new Dictionary<Type, IDiscriminatorConvention>();
private static Dictionary<BsonValue, HashSet<Type>> __discriminators = new Dictionary<BsonValue, HashSet<Type>>();
private static HashSet<Type> __discriminatedTypes = new HashSet<Type>();
private static ConcurrentDictionary<Type, bool> __discriminatedTypes = new ();
private static BsonSerializerRegistry __serializerRegistry;
private static TypeMappingSerializationProvider __typeMappingSerializationProvider;
// ConcurrentDictionary<Type, object> is being used as a concurrent set of Type. The values will always be null.
Expand Down Expand Up @@ -321,8 +321,7 @@ internal static bool IsDiscriminatorConventionRegisteredAtThisLevel(Type type)
/// <returns>True if the type is discriminated.</returns>
public static bool IsTypeDiscriminated(Type type)
{
var typeInfo = type.GetTypeInfo();
return typeInfo.IsInterface || __discriminatedTypes.Contains(type);
return type.IsInterface || __discriminatedTypes.ContainsKey(type);
}

/// <summary>
Expand Down Expand Up @@ -587,7 +586,8 @@ public static void RegisterDiscriminator(Type type, BsonValue discriminator)
// mark all base types as discriminated (so we know that it's worth reading a discriminator)
for (var baseType = typeInfo.BaseType; baseType != null; baseType = baseType.GetTypeInfo().BaseType)
{
__discriminatedTypes.Add(baseType);
// We expect that TryAdd will always return true, so no need to check the return value.
__discriminatedTypes.TryAdd(baseType, true);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it OK that we are ignoring the return value of TryAdd?

I understand that we expect it to always return true given the check on line 582.

Should we document that we are ignoring the return value on purpose by coding like this:

_ = __discriminatedTypes.TryAdd(baseType, true);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's safe to ignore the return value of TryAdd in the same way we ignored Add before (the return value has the same semantic).
Maybe adding a comment would make it clearer, I'm not a super fan of adding the discard operator.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting... I am a fan of the discard variable. I always prefer code to comments to document something.

But it's fine either way.
}
}
}
Expand Down