Why doesn't max_keys work

[scwcd]

if let Ok(list_object_bldr) = client.list_objects(&bucket) {
    let mut resp = list_object_bldr
        .use_api_v1(true)
        .delimiter(Some("/".to_string()))
        .prefix(Some(prefix))
        .marker(marker)
        .max_keys(Some(10))
        .build()
        .to_stream()
        .await;

    while let Some(objects_res) = resp.next().await {
        if let Ok(res) = objects_res {
            objects.prefix = res.prefix;
            objects.delimiter = res.delimiter;
            objects.is_truncated = res.is_truncated;
            objects.marker = res.marker;
            objects.next_marker = res.next_marker;

            for item in res.contents {
               ...
            }
        }
    }
}

[klauspost]

I think the max-keys is just a hint on how many to fetch per request. @HJLebbink

[scwcd]

Previously, using minio rs 0.1.0 was able to run normally

let args = match ListObjectsV1Args::new(&bucket) {
    Ok(mut args) => {
        args.delimiter = Some("/");
        args.prefix = Some(prefix.as_str());
        args.marker = marker;
        args.max_keys = Some(10);

        args
    }
    Err(e) => {
        error!("{}", e);
        return objects;
    }
};

match client.list_objects(&bucket) {
    Ok(res) => {
        objects.prefix = res.prefix;
        objects.delimiter = res.delimiter;
        objects.is_truncated = res.is_truncated;
        objects.marker = res.marker;
        objects.next_marker = res.next_marker;

        for item in res.contents {
            ...
        }
    }
    Err(e) => {
        error!("{}", e);
   }
}

But changing it to 0.4.0 would be problematic

[HJLebbink]

We have no idea what you were expecting. This is what our ai came up with:

  Based on the WebFetch summary, I have a high-level understanding: the user was trying to use .max_keys(Some(10)) to
  limit results to 10 objects per page, but the parameter wasn't working—results weren't being limited as expected.

  However, I don't have the full details of the specific problem. The summary is somewhat vague. The actual issue could
  have been:

  1. max_keys parameter wasn't being passed to the S3 API at all (missing implementation)
  2. max_keys parameter was malformed when sent to the server
  3. The builder didn't support max_keys in an ergonomic way
  4. Validation was missing, causing invalid values to be silently accepted or cause panics
  5. Documentation was unclear about how max_keys works

  Could you share what the specific symptom was that the user experienced? For example:
  - Did they get an error message?
  - Did all results get returned regardless of max_keys?
  - Was max_keys not accepted by the builder?
  - Did the server return more objects than the max_keys limit specified?

  This would help me confirm whether the solution we implemented fully addresses their original problem.

See #212

[HJLebbink]

But changing it to 0.4.0 would be problematic
@scwcd why would this be an issue (for you)?

[scwcd]

I need to view the content stored in minio with pagination in the application system. @HJLebbink

[klauspost]

@HJLebbink I think OP wants something that is "lower level" and gives more direct access to the call and then having to deal with continuation himself. So it seems like he is looking for "something else" rather than a bug fix.

[HJLebbink]

I need to view the content stored in minio with pagination in the application system. @HJLebbink

@scwcd Im still do not know what you really need. Head now contains better ergonomics for max_keys