fix(tools): allow whole-file reads of empty files - #7585

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

Question on the explicit-range case. The tool declares start_line as "Defaults to 1", but on this branch {} reads an empty file fine while {'start_line': 1} errors. The check keys on whether the arguments were passed, not on the range they produce, so every argument set that reads a whole 2-line file also errors on an empty one.

I ran the same args against a 2-line file and an empty file on this branch (89cc6a2), using LocalEnvironment + ReadFileTool.run_async:

two.txt   {}                                 {'status': 'ok', 'content': '     1\ta\n     2\tb\n'}
empty.txt {}                                 {'status': 'ok', 'content': ''}
two.txt   {'start_line': 1}                  {'status': 'ok', 'content': '     1\ta\n     2\tb\n'}
empty.txt {'start_line': 1}                  {'status': 'error', 'error': '`start_line` 1 exceeds file length (0 lines).', 'total_lines': 0}
two.txt   {'start_line': 0}                  {'status': 'ok', 'content': '     1\ta\n     2\tb\n'}
empty.txt {'start_line': 0}                  {'status': 'error', 'error': '`start_line` 1 exceeds file length (0 lines).', 'total_lines': 0}
two.txt   {'end_line': 5}                    {'status': 'ok', 'content': '     1\ta\n     2\tb\n'}
empty.txt {'end_line': 5}                    {'status': 'error', 'error': '`start_line` 1 exceeds file length (0 lines).', 'total_lines': 0}
two.txt   {'start_line': 1, 'end_line': 100} {'status': 'ok', 'content': '     1\ta\n     2\tb\n'}
empty.txt {'start_line': 1, 'end_line': 100} {'status': 'error', 'error': '`start_line` 1 exceeds file length (0 lines).', 'total_lines': 0}

The end_line-only error also names a start_line the caller never sent.

I see test_read_empty_file_with_line_range_returns_error pins {'start_line': 1} and {'end_line': 1} to the error on purpose. If that's not the intent, checking after start is computed, e.g. if total == 0 and start == 1: return {'status': 'ok', 'content': ''}. That covers {}, start_line 0 or 1 and any end_line, and still errors for start_line >= 2. The parametrized test would then cover those inputs as ok and keep only {'start_line': 2} as the error case. I tried that check on this branch: all six empty-file calls above return {'status': 'ok', 'content': ''}, and {'start_line': 2} still errors.

Checked: PR tests on main's _read_file_tool.py give 1 failed, 9 passed (test_read_empty_file_without_line_range). On the branch, 10 passed.

Thanks for the detailed reproduction. You are right: explicit defaults should behave like omitted arguments. I updated the PR in commit 638d932 to check the normalized range instead of whether the arguments were supplied.

The empty-file guard now requires total == 0, start == 1, and end == 0. This covers the examples you listed, including start_line=0/1 and end-only bounds, while preserving errors for start_line >= 2. I also require end == 0 so negative end lines retain their previous error behavior.

The expanded tests cover equivalent whole-file ranges on empty and two-line files, explicit first-line bounds, and invalid ranges. With the previous PR implementation they produce 8 failed and 17 passed; with the update, the environment-tool suite has 30 passed on each of Python 3.11, 3.12, and 3.13. The manual LocalEnvironment matrix and formatting/lint/compliance checks also pass. Full-suite validation remains pending.