InsertManyError has empty inserted_ids

[qm3ster]

Versions/Environment

1. What version of Rust are you using? 1.81
2. What operating system are you using? Linux
3. What versions of the driver and its dependencies are you using? 3.0.0 or current master branch (a025f5442d5445548aa3f2039da0237803c4a1d1)
4. What version of MongoDB are you using? 7.0.11
5. What is your MongoDB topology? replica set

Describe the bug

A clear and concise description of what the bug is.

collection.insert_one(doc!{_id: 2}).await?;
let result = collection.insert_many(vec![doc!{_id: 1},doc!{_id: 2}]).await;
if let ErrorKind::InsertMany(err) = *result.unwrap_err().kind {
    // this fails, in both ordered and unordered insert_many
    assert!(!err.inserted_ids.is_empty());
}

To Reproduce Steps to reproduce the behavior:

1. do either: a. an unordered insert where some _ids are new b. an ordered insert where the first _ids are new and a later one is duplicate
2. expect to see the successful insertions in inserted_ids
3. recoil in fear

P.S:

I would really love to see inserted_ids be a IndexMap or Vec<(K,V)> rather than a HashMap (what we have now) that randomizes order or a BTreeMap that sorts the keys even though they are ordered in the server response.

P.P.S:

The commit template says

Make sure you have read CONTRIBUTING.md completely

There is no CONTRIBUTING.md in the repository :v If it's reffering to github.com/mongodb/mongo/CONTRIBUTING.rst That now redirects to (github.com/mongodb/mongo/wiki)[https://github.com/mongodb/mongo/wiki] which tells me bug reports go in Jira and not here, and how to format my C++

[abr-egn]

inserted_ids is not a public field of InsertManyError; how are you accessing it?

[qm3ster]

Oh, that's wild, must have only been in debug prints so far! I do need access to that as well, as available in other drivers. Should I make an additional issue for that?

While investigating how this is happening, I fixed this issue for my usage for now, and submitted that as a PR. I believe that the approach I took has an overall correct vibe, but some of the details like naming may need to be reviewed before I can apply a similar fix in some other places.