edmc-ss opened a new issue, #7809:
URL: https://github.com/apache/opendal/issues/7809
### Summary
The Swift service does not support `start_after` for listing:
`Capability::list_with_start_after` is `false`, and a user-supplied
`start_after` is silently ignored on the wire (no `marker` is sent), so the
lister returns the full keyspace.
### Reproduce
Against any Swift endpoint, with objects `a`, `b`, `c`, `d`:
```rust
let cap = op.info().full_capability();
assert!(!cap.list_with_start_after); // false today
let got: Vec<_> = op.list_with("").start_after("b").recursive(true).await?
.into_iter().map(|e| e.path().to_string()).collect();
// expected ["c", "d"], actual ["a", "b", "c", "d"] — start_after ignored
```
### Why it matters
Range-split / sharded enumeration (tiling the keyspace into
`start_after`-bounded ranges walked in parallel) is a common pattern for large
flat buckets. It works on S3/GCS but not Swift, even though the OpenStack Swift
API supports it via the [`marker` pagination
parameter](https://docs.openstack.org/swift/latest/api/pagination.html)
(exclusive start-after).
### Proposed fix
It's small: `SwiftCore::swift_list` already accepts a `marker`, and
`SwiftLister` already pages through it via `ctx.token`. Only the initial seed
and the capability flag are missing. Seeding the first page's marker from
`OpList::start_after()` (made absolute, like the S3 lister) and advertising
`list_with_start_after` is sufficient; the capability-gated behavior tests then
cover it. PR follows.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
