fix(cliproxyapi): sync recovered auth files to R2 on startup - #472
Conversation
Previously, auth files recovered from dotfiles were merged to local storage but never uploaded to R2. This caused "key does not exist" errors when cliproxyapi tried to read auth files directly from object storage. Now start.sh always syncs local auth files to R2 after the recovery step, ensuring all auth files (recovered or created locally) are available in both the primary auths/ and backup locations. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
|
You do not have enough credits to review this pull request. Please purchase more credits to continue. |
📝 WalkthroughSummary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings. WalkthroughA post-merge synchronization block is added to the start.sh script that syncs local authentication files to a primary R2 object store location and a secondary backup location when auth files are present. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
Summary of ChangesHello @shunkakinoki, I'm Gemini Code Assist1! 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 resolves a critical issue where Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe 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
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 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. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
Mesa DescriptionTL;DRFixed "key does not exist" error when running What changed?Modified Description generated by Mesa. Update settings |
There was a problem hiding this comment.
Code Review
This pull request correctly identifies and fixes a bug where recovered auth files were not synced to R2 on startup. The added logic to sync local auth files is a good solution. My review focuses on improving the error handling and logging within the new shell script block. I've provided suggestions to make the error handling more robust, ensuring that critical sync failures cause the script to exit as expected and that log messages are consistently routed to the correct output streams for easier debugging.
| --endpoint-url="${OBJECTSTORE_ENDPOINT}" \ | ||
| --no-progress \ | ||
| "$AUTH_DIR/" \ | ||
| "s3://cliproxyapi/auths/" 2>&1 && echo "✅ Auth files synced to R2 auths/" >&2 || echo "⚠️ Failed to sync auth files to R2" >&2 |
There was a problem hiding this comment.
The error handling for this critical sync operation has a couple of issues:
-
Incorrect Error Redirection: The use of
2>&1sends theawscommand's standard error to standard output. Given that your service configuration separates stdout and stderr into different log files, this would cause importantawserror messages to be logged in/tmp/cliproxyapi.loginstead of/tmp/cliproxyapi.error.log, making debugging more difficult. -
Failure Is Not Fatal: The
|| echo ...construct prevents a non-zero exit code from theawscommand from propagating. Sinceset -eis active, a failure in this critical step should terminate the script. However, the current implementation will only print a warning and continue, which could lead to the very "key does not exist" errors this change is intended to fix.
My suggestion below corrects both issues by removing the redirection and ensuring the script exits upon failure.
| "s3://cliproxyapi/auths/" 2>&1 && echo "✅ Auth files synced to R2 auths/" >&2 || echo "⚠️ Failed to sync auth files to R2" >&2 | |
| "s3://cliproxyapi/auths/" && echo "✅ Auth files synced to R2 auths/" >&2 || { echo "⚠️ Failed to sync auth files to R2" >&2; exit 1; } |
| --endpoint-url="${OBJECTSTORE_ENDPOINT}" \ | ||
| --no-progress \ | ||
| "$AUTH_DIR/" \ | ||
| "s3://cliproxyapi/backup/auths/" 2>&1 && echo "✅ Auth files synced to R2 backup/" >&2 || true |
There was a problem hiding this comment.
Similar to the primary sync command, this line redirects stderr to stdout (2>&1). This can make debugging more difficult by sending aws error messages to the standard log file instead of the error log file.
To improve logging consistency, I recommend removing the 2>&1 redirection. The || true part correctly ensures that a failure in this non-critical backup sync does not halt the script.
| "s3://cliproxyapi/backup/auths/" 2>&1 && echo "✅ Auth files synced to R2 backup/" >&2 || true | |
| "s3://cliproxyapi/backup/auths/" && echo "✅ Auth files synced to R2 backup/" >&2 || true |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
home-manager/services/cliproxyapi/scripts/start.sh (1)
73-95: LGTM! Sync logic correctly addresses the PR objective.The implementation correctly syncs local auth files to R2 after the dotfiles merge, preventing the "key does not exist" error. The approach is sound:
- Idempotent
aws s3 syncensures safe repeated execution- Primary location sync provides failure visibility
- Backup location sync adds redundancy without blocking on failures
Optional: Document why backup failures are silently ignored
Line 94 uses
|| trueto silently ignore backup sync failures, while line 85 displays a warning for primary sync failures. This difference is intentional but undocumented. Consider adding a brief comment:# Also sync to backup location for redundancy + # Failures are silently ignored since backup is non-critical AWS_ACCESS_KEY_ID="${OBJECTSTORE_ACCESS_KEY}" \
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
home-manager/services/cliproxyapi/scripts/start.sh
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{sh,bash}
📄 CodeRabbit inference engine (CLAUDE.md)
Use shfmt with 2-space indentation for shell scripts
**/*.{sh,bash}: Use 2 spaces for indentation in shell scripts
Add proper shebang lines to shell scripts
Follow shellcheck recommendations in shell scripts
Document complex commands in shell scripts
Use consistent variable naming in shell scripts
Files:
home-manager/services/cliproxyapi/scripts/start.sh
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (13)
- GitHub Check: e2e-run (Ubuntu, ubuntu-latest)
- GitHub Check: e2e-run (NixOS, ubuntu-latest)
- GitHub Check: e2e-run (MacOS, macos-latest)
- GitHub Check: nix-nixos
- GitHub Check: shell-lint
- GitHub Check: shell-test
- GitHub Check: nix-darwin
- GitHub Check: docker-build-push (linux/arm64, arm64, ubuntu-24.04-arm)
- GitHub Check: nix-linux
- GitHub Check: docker-build-push (linux/amd64, amd64, ubuntu-latest)
- GitHub Check: lua-neovim
- GitHub Check: lua-neovim-test
- GitHub Check: lua-hammerspoon
Summary
cliproxyapi --claude-loginProblem
Previously, when cliproxyapi created auth files locally (e.g., via
--claude-login), they were stored in~/.cli-proxy-api/objectstore/auths/but never uploaded to R2. This caused "key does not exist" errors when cliproxyapi tried to read these files from object storage.Solution
Modified
start.shto always sync local auth files to R2 after pulling from backup. This ensures:s3://cliproxyapi/auths/) and backup (s3://cliproxyapi/backup/auths/) locations stay in syncAlso cleaned up
backup-auth.shto remove the now-defunct dotfiles sync logic.Changes
start.sh: Added bidirectional sync (pull from R2, then push local changes back)backup-auth.sh: Removed dotfiles recovery/sync logic (directory is gitignored)Test Plan
cliproxyapi --claude-loginworks without errors🤖 Generated with Claude Code