[CSHARP-1933] Mapping a sub-document throws System.FormatException with a duplicate element name Created: 06/Mar/17  Updated: 27/Oct/23  Resolved: 07/Mar/17

Status: Closed
Project: C# Driver
Component/s: Serialization
Affects Version/s: 2.4.2
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Huw Leonard [X] Assignee: Robert Stam
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

VS2015



 Description   

An exception of type System.FormatException is thrown, with the following description:

Additional information: An error occurred while deserializing the Settings property of class Application.Models.User: Duplicate element name 'admin'.

The offending code (a test case created to trigger the bug in isolation):

        public void TriggerUserBug()
        {
            var connection = ConfigurationManager.AppSettings["MongoDBConnection"];
            var database = ConfigurationManager.AppSettings["DatabaseName"];
 
            var client = new MongoClient(connection);
            IMongoDatabase db = client.GetDatabase(database);
            IMongoCollection<User> collection = db.GetCollection<User>("users");
 
            var filter = Builders<User>.Filter.Eq("_id", ObjectId.Parse("533ab4de616c6565c9bc0000"));
            var result = collection.Find(filter).FirstOrDefault(); // generates the exception
 
            Assert.AreEqual("533ab4de616c6565c9bc0000", result.Id.ToString());
        }

The User object declares the sub-document like this:

        [BsonElement("settings")]
        public BsonDocument Settings { get; set; }

The string "admin" does not appear in the code at all.

The data in the MongoDB sub-document looks like:

    "settings" : {
        "admin" : {
            "ext_number" : "999"
        }
    },

The string "admin" does not appear anywhere else in the user document (which is very large, which is why I haven't included it here).



 Comments   
Comment by Huw Leonard [X] [ 07/Mar/17 ]

That would certainly explain the situation, as well as why created test data doesn't trigger the same result. The data was originally created via mongoid, so I imagine that that behaves differently than the C# driver as well. It seems that this is not a bug per se, so thanks for clearing it up.

Comment by Robert Stam [ 07/Mar/17 ]

It's probable that your document stored in the database really does have a duplicate element.

But it occurs to me that if you are looking at the documents using the shell you won't be able to see that. The shell reacts to documents with duplicate documents differently than the C# driver does. If the shell sees a document with duplicate elements the second one simply overwrites the first one.

Comment by Robert Stam [ 06/Mar/17 ]

I am unable to reproduce this.

I adapted the code you provided to a standalone console application. Let me know if you think I need to do something different to reproduce.

using System;
using System.Linq;
using MongoDB.Bson;
using MongoDB.Driver;
 
namespace TestCSharp1933
{
    public class User
    {
        public ObjectId Id { get; set; }
        public BsonDocument Settings { get; set; }
    }
 
    public static class Program
    {
        public static void Main(string[] args)
        {
            var client = new MongoClient("mongodb://localhost");
            var database = client.GetDatabase("test");
            var collection = database.GetCollection<User>("test");
 
            var id = ObjectId.Parse("533ab4de616c6565c9bc0000");
            var user = new User
            {
                Id = id,
                Settings = BsonDocument.Parse("{ admin : { ext_number : 999 } }")
            };
 
            database.DropCollection("test");
            collection.InsertOne(user);
 
            var filter = Builders<User>.Filter.Eq("_id", id);
            var result = collection.Find(filter).FirstOrDefault();
 
            Console.WriteLine(result.ToJson());
            Console.ReadLine();
        }
    }
}

Generated at Wed Feb 07 21:41:06 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.