storage: `Recommended` read-resume policy does not resume on `ABORTED`, the status the service uses to close an idle `BidiReadObject` stream

Open Beginner friendly
  • Is something wrong?
#7,344 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
62/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
grpc, rust
Domain
cloud

Research direction

Start in src/storage/src/read_resume_policy.rs, at is_transient_code (around line 154), and check how Recommended maps its result to ResumeResult. The issue asks either to add Code::Aborted to the transient list or to match the idle-close status specifically, so confirm which the maintainers want before editing. Done means a test where an Aborted status under Recommended returns a resumable result, plus existing policy tests still passing.

Written by the indexing model from the issue text.

Description

api: storage

What happens

read_resume_policy::is_transient_code (src/storage/src/read_resume_policy.rs line 154 on
main and in 1.21.0) treats Unavailable, ResourceExhausted, Internal and
DeadlineExceeded as resumable. Aborted is not in the list, so Recommended returns
ResumeResult::Permanent for it and the bidi worker stops.

Why it matters

Cloud Storage engineering told us, through our support case, that an idle BidiReadObject
stream is pruned after roughly six minutes and that the intended signal is gRPC ABORTED with a
message like "Idle stream closed...". What the client receives today is an HTTP/2
RST_STREAM(INTERNAL_ERROR) with no trailers, which surfaces as a transport error and is
resumed. The day the service sends the documented status, every client on the default policy
stops resuming idle-pruned streams: the worker parks in its permanent-error arm and every later
read on that descriptor fails (with #6688 unfixed, by a panic on the next read_range).

An idle-prune ABORTED on a descriptor with a valid read_handle is resumable by construction:
the resume is the same RPC carrying the handle, and the object has not changed.

Reproduction

Fake google.storage.v2.Storage (tonic) implementing BidiReadObject. Open a descriptor, read
one range, leave it idle, have the fake end the stream with Status::aborted("Idle stream closed"). Observed on 1.21.0: zero reconnect attempts reach the fake; the descriptor is dead.
With the fake ending the same idle stream with Unavailable instead, the client reconnects and
the next read succeeds.

Expected

Add Code::Aborted to is_transient_code, or match the idle-close status specifically if its
message or error details are stable. Either way Recommended should resume it.

Workaround

open_object(...).with_read_resume_policy(...) with a policy that continues on Aborted. We
recover at the pool level instead (evict the descriptor on a failed read and retry once on a
fresh stream), so the cost today is one failed read.

Environment

google-cloud-storage 1.21.0, gRPC transport, BidiReadObject via open_object; main has the
same code as of 2 Nov 2026.

Dominant language
Rust
Stars
972
Forks
163
Avg merge
1d 13h
Merged PRs (30d)
202

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from googleapis/google-cloud-rust

All issues in googleapis/google-cloud-rust

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.