fix(executor): warn to stderr when 2xx response has empty body

[hoyt-harness]

Problem

When an API call succeeds (2xx HTTP status) but returns an empty response
body, execute_method() silently discards the response: no output, no
warning, exit 0. Users see nothing and have no indication of what happened.

This is tracked in #740 (sub-issue: empty-body diagnostic). The companion
fix for the +read --format global flag collision was submitted in #751.

Root cause

In execute_method(), after reading body_text, handle_json_response()
is called unconditionally. When body_text is empty, serde_json::from_str
fails, the else branch runs, and the condition
!capture_output && !body_text.is_empty() is false — nothing is printed,
no error is returned, and the function exits with Ok(None).

Fix

Add a guard in execute_method() between reading body_text and calling
handle_json_response(): if body_text is empty on a 2xx response, print
a Warning: message to stderr (including the method ID and HTTP status) and
break out of the pagination loop.

The exit code remains 0 because the HTTP call itself succeeded. A non-zero
exit was considered, but GwsError::Other would also write
{"error": {"code": 500, "reason": "internalError"}} to stdout, which is
misleading for a 200 OK response and breaks the stdout=data contract.
Scripts needing automated detection of empty-body responses should check
stderr for the Warning: prefix.

$ gws drive files.get fileId=abc123
Warning: drive.files.get returned HTTP 200 with an empty response body.

Tests

Two new unit tests for handle_json_response():

• test_handle_json_response_empty_body_returns_no_continue — verifies
  empty body returns Ok(false) without panicking and does not increment
  pages_fetched. This covers the underlying function behavior (the new
  guard in execute_method() prevents it from being called with an empty
  body in practice, but the function handles it gracefully as a fallback).
• test_handle_json_response_valid_json_increments_pages — regression test
  for the normal JSON path.

Testing the execute_method() guard end-to-end would require a mock HTTP
server; there is no such infrastructure in this crate currently.

Other changes

Collapses a pre-existing clippy::collapsible_match in
helpers/script.rs (same warning present on upstream/main).

[changeset-bot]

🦋 Changeset detected

Latest commit: 612fcd5

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@googleworkspace/cli	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a silent failure issue where successful API calls with empty response bodies provided no feedback to the user. By implementing a diagnostic warning, users are now alerted to these cases via stderr, ensuring better transparency without breaking existing output contracts. Additionally, the change includes regression testing and minor code quality improvements.

Highlights

• Empty Body Diagnostic: Added a guard in execute_method to print a warning to stderr when an API call returns a 2xx status with an empty response body, improving visibility for users.
• Unit Testing: Introduced two new unit tests for handle_json_response to verify behavior with empty and valid JSON bodies.
• Code Cleanup: Refactored a match statement in helpers/script.rs to resolve a clippy::collapsible_match warning.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Generative AI Prohibited Use Policy, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a diagnostic warning for successful API calls that return an empty response body. The execute_method function now checks for empty bodies, logs a warning to stderr, and breaks the execution loop. New unit tests verify this logic and ensure correct pagination behavior. Additionally, a match arm in script.rs was refactored for better readability using a match guard. I have no feedback to provide.