Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.32%. Comparing base (cf91973) to head (4b24b77).
⚠️ Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main    #3328      +/-   ##
==========================================
+ Coverage   96.29%   96.32%   +0.02%     
==========================================
  Files         113      114       +1     
  Lines        4510     4517       +7     
==========================================
+ Hits         4343     4351       +8     
+ Misses        167      166       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

This PR still needs tests, but I welcome thoughts on whether this is 1) the right location and 2) the right way to expose this helper.

thoughts

I really like the ergonomics of the trait extension. I think it is nicer than a fn of a builder.

I am cool with it in model_ext.

The only thing that isn't obvious to me is whether the loop should have some sort of exhaustion policy. Like if we are making progress too slowly.

I don't think we need a policy. I think even if we want such a policy, we would add it to the storage::request_options::RequestOptions. <-- oh wait this doesn't work. I mixed up my clients

thoughts

I really like the ergonomics of the trait extension. I think it is nicer than a fn of a builder.

💯

I am cool with it in model_ext.

We are extending builders, so builder_ext seems slightly better to me?

The only thing that isn't obvious to me is whether the loop should have some sort of exhaustion policy. Like if we are making progress too slowly.

I don't think we need a policy. I think even if we want such a policy, we would add it to the storage::request_options::RequestOptions. <-- oh wait this doesn't work. I mixed up my clients

I would keep this simple. If we want a loop with exhaustion we can add another extension function (in the future) that transforms the rewrite into a stream. Then they have all the power of streams to do things like:

    use futures::stream::StreamExt;
    let builder = client
        .rewrite_object()
        .set_source_bucket(format!("projects/_/buckets/{source_bucket_id}"))
        .set_source_object(SOURCE_NAME)
        .set_destination_bucket(format!("projects/_/buckets/{dest_bucket_id}"))
        .set_destination_name(DEST_NAME);

  let moved = builder
      .to_stream() // A new thing
      .take(100) // at most 100 attempts.
      .map(|v| { /* return some error if the stream is too slow */ })
      .try_fold(None, |object, response| if response.done { response.resource } else { object })

A simple function like the one provided in this PR will handle 90% of the cases. We can add the streams for the next 9%, and customers can fallback to an explicit loop for the remaining 1%.

I am cool with it in model_ext.

We are extending builders, so builder_ext seems slightly better to me?

Created builder_ext and moved this there.

This PR still needs tests

Tests are added!