[yuxin00j]

Summary

Adds Rapid system tests for the opt-in zero-copy BidiReadObjectResponse parser (GCS_PYTHON_CLIENT_ZERO_COPY_BIDI_READ=1) from #18627, as requested in its review:

• test_mrd_zero_copy_bidi_read, a new test for behavior specific to the parser: chunk types, buffer destinations and short reads.
• Every other test in tests/system/test_rapid.py that calls download_ranges now runs with the parser off and on, and with accepts_memoryview set to False and True.

They run with the existing Rapid system tests (and in manual RCU runs); no CI changes.

test_mrd_zero_copy_bidi_read

The test writes one 5 MiB appendable object, finalizes it, and reads it back over a single AsyncMultiRangeDownloader stream with the parser enabled:

• The stream uses the zero-copy BidiReadObject RPC, and the downloader still gets the object size from the open response.
• A full-object read into a default write() destination receives only bytes chunks.
• With download_ranges(..., accepts_memoryview=True), chunks are memoryviews when the installed google-crc32c accepts memoryview and bytes otherwise (for example google-crc32c 1.9.0). The chunks kept after the call still match the object data.
• One download_ranges call fills a bytearray and a writable memoryview slice of a larger buffer, 2.5 MiB each. Guard bytes around the slice catch out-of-range writes, and both buffers are cleared afterwards, which fails if the SDK kept a view of either one.
• A read clamped at EOF into a buffer raises BufferError and leaves the stream open. The buffer is cleared while the exception is still held, which checks that the SDK released its view itself, and the next read on the same downloader succeeds.

Existing read tests

Two new fixtures: zero_copy_bidi_read sets GCS_PYTHON_CLIENT_ZERO_COPY_BIDI_READ to 0 or 1 through monkeypatch, so nothing leaks into later tests on the shared session-scoped gRPC client, and accepts_memoryview is passed to every download_ranges call. The 14 tests that call download_ranges take both, on top of their multi_stream_config parameter from #18537, so each runs in eight combinations: those tests go from 62 to 248 cases and the file from 73 to 260. test_mrd_zero_copy_bidi_read keeps its own settings. In the python-sdk-zb-system-test check, pytest takes 156 s instead of 47 s on main (252 passed; the 8 skipped cases are the read-handle test, which was already skipped).

Testing

cd packages/google-cloud-storage
ruff check --select I tests/system/test_rapid.py
ruff format --check --target-version=py310 tests/system/test_rapid.py
flake8 tests/system/test_rapid.py

I ran the new test locally against an in-process grpc.aio server implementing BidiWriteObject and BidiReadObject (responses of at most 2 MiB, with and without an empty final response on a 2 MiB boundary), once with google-crc32c 1.9.0 and once with a google-crc32c build from main that accepts memoryview. Against the same server I ran the 10 parametrized tests it can serve in all their combinations, including both multi_stream_config values, checking that each stream used the expected parser and each call passed the expected accepts_memoryview; the cross-region, write-handle and append-to-existing-object tests need a real bucket, and the read-handle test is skipped. The python-sdk-zb-system-test check runs everything against a real Rapid bucket.

[gemini-code-assist]

Code Review

This pull request introduces a new system test, test_mrd_zero_copy_bidi_read, to verify zero-copy BidiReadObject reads across write and buffer destinations. The feedback suggests improving the test's code quality by using isinstance for type checking to remain idiomatic and consistent, removing a redundant assertion on exc_info.tb after a pytest.raises block, and deleting unnecessary del writer and gc.collect() calls that could potentially raise a NameError if the gc module is not imported.

[yuxin00j]

/gcbrun

[yuxin00j]

/gcbrun

[yuxin00j]

/gcbrun

[yuxin00j]

CI should be fixed by #18981

[parthea]

/gcbrun