fix(services/yandex-disk): end the listing when a response has no _embedded

[PDGGK]

Which issue does this PR close?

None — found while reading the service.

Rationale for this change

next_page handled a 200 like this:

match resp.status() {
    http::StatusCode::OK => {
        ...
        if let Some(embedded) = resp.embedded {
            ...
            return Ok(());
        }
        // no else
    }
    http::StatusCode::NOT_FOUND => { ctx.done = true; return Ok(()); }
    _ => { return Err(parse_error(resp)); }
}

Ok(())   // <- done still false, entries still empty

A response without _embedded falls all the way out with ctx.done false and nothing pushed. That is exactly PageLister::next's loop condition:

loop {
    if let Some(entry) = self.ctx.entries.pop_front() { return Ok(Some(entry)); }
    if self.ctx.done { return Ok(None); }
    self.inner.next_page(&mut self.ctx).await?;
}

so the same HTTPS request is re-issued for ever — a hang, plus unbounded request volume against the user's Yandex quota.

_embedded is what a folder carries. A file has none, which is why the field is Option<Embedded>:

pub struct MetainformationResponse {
    #[serde(rename = "type")]
    pub ty: String,
    pub path: String,
    ...
    #[serde(rename = "_embedded")]
    pub embedded: Option<Embedded>,
}

And listing a file path is a documented contract rather than a misuse — core/tests/behavior/async_list.rs:

pub async fn test_list_prefix(op: Operator) -> Result<()> {
    ...
    op.write(&path, content).await.expect("write must succeed");

    let obs = op.list(&path).await?;
    assert_eq!(obs.len(), 1);
    assert_eq!(obs[0].path(), path);
    assert_eq!(obs[0].metadata().mode(), EntryMode::FILE);

What changes are included in this PR?

The no-_embedded branch now emits the file the response describes and ends the listing. The response is that file's own metainformation, and parse_info already accepts it — it is the same type as the items inside _embedded.

The entry construction is shared between the two branches as build_entry, and the page handling moves into consume_page so it can be driven without an HTTP round trip.

There is no directory under .github/services for yandex-disk, so nothing exercised any of this.

If you would rather keep the change minimal, ctx.done = true alone stops the loop — but it leaves list on a file returning nothing, which is what test_list_prefix forbids.

Tests

	file (no _embedded)	complete folder page	partial folder page
fall-through restored (current main)	FAILED	ok	ok
this PR	ok	ok	ok

cargo test -p opendal-service-yandex-disk --lib → 5 passed. cargo fmt --all -- --check and cargo clippy -p opendal-service-yandex-disk --all-targets both clean.

Are there any user-facing changes?

Yes — list on a yandex-disk path that is a file returns that file as a single entry and terminates, instead of looping on the same request indefinitely. Folder listings are unchanged.

[PDGGK]

Slimmed this to match the shape you asked for on #8068, #8069 and #8071, rather than making you say it again.

Both extracted helpers are gone; the no-_embedded branch is written inline and the existing folder loop is untouched. resp becomes mut so embedded can be taken out of it, leaving the rest of the response available for the file case. Diff is +24/-8.

The fix is unchanged: a 200 with no _embedded — which is what a file returns — used to fall out with ctx.done still false and nothing pushed, and that is exactly PageLister::next's loop condition, so the same request was re-issued for ever. It now emits the file the response describes and ends the listing, which is also what test_list_prefix in the behaviour suite expects from list on a file path.

The removed tests drove consume_page directly, without an HTTP round trip, and were the only coverage this service has — there is no .github/services/yandex-disk. Flagging that rather than arguing for them.

[erickguan]

No need for explanation.

[PDGGK]

Cut. The why is in the commit message instead.

[erickguan]

Can you cut the comment?