googleapis / googleapis/google-cloud-rust

Updating ReadRange on ReadObject does not reset read_limit, causing data truncation or panic

Open Beginner friendly
#6,679 0 comments 0 reactions 0 assignees View on GitHub
api: storage type: bug
Dominant language
Rust
Stars
955
Forks
144
Avg merge
1d 5h
Merged PRs (30d)
279

Description

Unconfirmed. This is the result of a search with Gemini, may be a false positive.

In `crate::model::ReadObjectRequest::with_range`, modifying `range` updates `read_offset` and `read_limit`:

https://github.com/googleapis/google-cloud-rust/blob/f02b42c2ac5720334cd2b5335824bd4166264527/src/storage/src/model_ext.rs#L286-L307

When a caller sets `ReadRange::head(100)` or `ReadRange::segment(offset, limit)` on a `ReadObject` request builder via `set_read_range`:

https://github.com/googleapis/google-cloud-rust/blob/f02b42c2ac5720334cd2b5335824bd4166264527/src/storage/src/storage/read_object.rs#L283-L286

`read_offset` is set to `0` and `read_limit` is set to `100`.

However, the `RequestedRange::Offset` and `RequestedRange::Tail` branches in `with_range` update `self.read_offset` without resetting `self.read_limit = 0;`:
1. If the caller subsequently calls `.set_read_range(ReadRange::all())` (or `ReadRange::offset(...)`), `read_limit` remains `100`. The download still requests only the first 100 bytes (e.g. `Range: bytes=0-99`) rather than downloading the entire object, causing silent data truncation.
2. If the caller subsequently calls `.set_read_range(ReadRange::tail(10))`, `read_offset` becomes `-10` while `read_limit` remains `100`. When constructing the HTTP request, this triggers an `unreachable!()` panic:

https://github.com/googleapis/google-cloud-rust/blob/f02b42c2ac5720334cd2b5335824bd4166264527/src/storage/src/storage/read_object.rs#L621-L625

`with_range` should reset `self.read_limit = 0;` when handling `RequestedRange::Offset` and `RequestedRange::Tail`.

Contributor guide

Open the contributing guide

Research direction

Start in src/storage/src/model_ext.rs around ReadObjectRequest::with_range, then inspect set_read_range and HTTP range construction in src/storage/src/storage/read_object.rs. Check the Offset and Tail cases against the Head, Segment, and All transitions. Done means switching ranges no longer truncates an All or Offset request and no longer reaches the documented panic for Tail.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
api, cloud
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
76/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.