RUST-1743 Question: GridFS is the rust driver compatible with the java driver?

[jse1t5]

Versions/Environment

1. What version of Rust are you using? 1.70
2. What operating system are you using? macOS Ventura 13.4.1
3. What versions of the driver and its dependencies are you using?

• https://github.com/rust-lang/crates.io-index#[email protected]
• https://github.com/rust-lang/crates.io-index#[email protected]

4. What version of MongoDB are you using? 5.0.12
5. What is your MongoDB topology standalone

Describe the bug

We're actually trying to read a file from a GridFsBucket in Java which was created in Rust.
Java claims that it cannot cast a Long value into an Integer.

Im not sure why this happens but in my case on the Upload side in Rust the "chunkSize" in "fs.files" and "n" in "fs.chunks" has the type int64.
It seems like the driver is implemented with a u32 ?!

https://github.com/mongodb/mongo-rust-driver/blob/v2.6.1/src/gridfs.rs#L55
https://github.com/mongodb/mongo-rust-driver/blob/v2.6.1/src/gridfs.rs#L34

Currently we use the Java driver version:

<dependency>
      <groupId>org.mongodb</groupId>
      <artifactId>mongodb-driver-sync</artifactId>
      <version>4.6.1</version>
      <scope>compile</scope>
</dependency>

A File upload on the java side stores chunkSize and n as i32.

To Reproduce
Steps to reproduce the behavior:

1. Create File via GridFsBucket in Rust
2. Read File via GridFsBucket in Java

For now the following Code fixes my Problem but it would be nice to remove this Workaround:

async fn fix_mongodb_types(db: &DB, oid: &Bson) -> anyhow::Result<()> {
    let mut opts = FindOneOptions::default();
    opts.projection = Some(doc! { "chunkSize": 1});
    let file = db.client().collection::<DocChunkSize>("fs.files").find_one(doc! { "_id": &oid }, Some(opts)).await?.unwrap();
    db.client().collection::<Document>("fs.files").update_one(
        doc! { "_id": oid }, 
        doc! {
        "$set": {
            "chunkSize": Bson::Int32(file.chunk_size as i32)
        }
    }, None).await?;
    let mut opts = FindOptions::default();
    opts.projection = Some(doc! { "_id": 1, "n": 1 });
    let mut chunks = db.client().collection::<DocN>("fs.chunks").find(doc! { "files_id": &oid }, None).await?;
    while let Some(ch) = chunks.next().await {
        if let Ok(ch) = ch {
            db.client().collection::<Document>("fs.chunks").update_one(
                doc! { "_id": &ch.id }, 
                doc! {
                "$set": {
                    "n": Bson::Int32(ch.n as i32)
                }
            }, None).await?;
        }
    }
    Ok(())
}

[Logarithmus]

Clearly Java driver is wrong here, because having negative number of chunks or chunk size makes absolutely no sense. Before Java 8, there was absolutely no way of using unsigned numbers in Java. Currently you can use Integer wrapper class for this. I guess mongodb java driver needs some modification for this to work.

[abr-egn]

Thank you for this report!

This is indeed a bug in the Rust driver - because bson has no representation for unsigned numbers, the Rust bson crate stores them as the next-wider signed integer type. In this case, it meant that the fields in question were being stored as int64, and the specification requires them to be int32. #941 will fix this, and will be in our next release (this week).

[abr-egn]

The fix for this is included in release 2.7.0-beta.