[mernst]

No description provided.

[coderabbitai]

Warning

Review limit reached

@mernst, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 46 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: a8d642b6-4c4e-4016-8088-e2e46690b17c

📥 Commits

Reviewing files that changed from the base of the PR and between 5844710 and fbf48d3.

📒 Files selected for processing (3)

• README.md
• check-google-java-format.py
• run-google-java-format.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude-review2

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[mernst]

@claude review

[claude]

Claude finished @mernst's task in 2m 32s —— View job

---

Claude finished reviewing this PR

• Gather context (diff, repo files, CLAUDE.md)
• Review changes in run-google-java-format.py
• Review changes in check-google-java-format.py
• Review changes in README.md
• Post final review feedback

Summary

This is a solid, well-scoped cleanup: it makes urlretrieve atomic (temp file + rename, matching the original file's permission bits), removes the now-redundant double-temp-file dance in run-google-java-format.py, replaces a private-API usage (tempfile._get_candidate_names()) with a simple counter, tightens the zip(..., strict=True) loop, and improves the troubleshooting text in the README to match the actual error message that's raised. No functional issues found.

Notes

run-google-java-format.py:117-137 / check-google-java-format.py:68-88 — urlretrieve is duplicated verbatim between the two scripts. This looks intentional rather than an oversight: each script is designed to be usable standalone (they fetch each other via raw GitHub URLs, see under_git/urlretrieve usage a few lines below), so sharing a module isn't really an option here. Just flagging in case a future shared-helper approach is ever considered.

Minor/edge case — in urlretrieve, if tmp_path.chmod(...) or tmp_path.rename(filename) (lines 134-137 / 85-88) raises after a successful download, the temp file created in filename.parent is left behind uncleaned, since that cleanup only happens inside the try/except BaseException around the download itself. This is a very unlikely failure mode (same-directory rename, chmod on a file you just created) and the caller's except Exception still produces a correct error message, so this is low severity — just noting it as the one gap in an otherwise thorough atomic-write implementation.

check-google-java-format.py:106-116 — good fix replacing tempfile._get_candidate_names() (private API, previously needed ty/ruff ignore comments) with a plain itertools.count()-based counter. Since names are now sequential rather than random, uniqueness relies entirely on the per-run mkdtemp directory (created with restrictive permissions) rather than on the name itself — that's fine, but worth being aware of if this function is ever reused in a context without a private temp directory.

check-google-java-format.py:153 — switching from enumerate(files) + indexing into temps[i] to zip(files, temps, strict=True) is a nice correctness improvement; strict=True will now raise loudly if the two lists ever get out of sync instead of silently mis-pairing or truncating.

README.md:464-466 — the updated troubleshooting text (Problem while retrieving ...) matches the actual exception message raised at run-google-java-format.py:156, so the docs stay accurate.

I wasn't able to run ruff/ty/tests in this sandbox (no network/tool access for uv/ruff install), so this review is based on manual reading only — worth a normal CI pass before merge.