Public-readiness fixes (Tasks 1–5 combined)#47
Conversation
Co-authored-by: Aanish Bhirud <baanish@users.noreply.github.com>
Co-authored-by: Aanish Bhirud <baanish@users.noreply.github.com>
Co-authored-by: Aanish Bhirud <baanish@users.noreply.github.com>
Co-authored-by: Aanish Bhirud <baanish@users.noreply.github.com>
Co-authored-by: Aanish Bhirud <baanish@users.noreply.github.com>
Co-authored-by: Aanish Bhirud <baanish@users.noreply.github.com>
Co-authored-by: Aanish Bhirud <baanish@users.noreply.github.com>
Co-authored-by: Aanish Bhirud <baanish@users.noreply.github.com>
Co-authored-by: Aanish Bhirud <baanish@users.noreply.github.com>
|
Warning Review limit reached
Next review available in: 3 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: defaults Review profile: CHILL Plan: Free Run ID: 📒 Files selected for processing (11)
Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login. Comment |
| let output = Command::new("crontab") | ||
| .arg("-l") | ||
| .output() | ||
| .context("Failed to run `crontab -l`")?; |
There was a problem hiding this comment.
WARNING: Installing cron now aborts qr init when the crontab binary is absent
Command::new("crontab").arg("-l").output() returns an Err (not a non-zero exit) when the crontab binary is not installed (minimal containers, some WSL/CI images). The previous implementation had a dedicated Err(_) arm that printed the cron_line and let init continue; this rewrite propagates the error via ?, so an explicit "yes" to the cron prompt fails the whole qr init after the config and wrapper have already been written (scan and price fetch never run). Consider restoring a graceful fallback that prints the manual cron line and logs the failure to stderr when crontab cannot be spawned.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Incremental review (commit
Files Re-verified (5 files)
Previous Review Summaries (2 snapshots, latest commit b99e5f7)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit b99e5f7)Status: No Issues Found | Recommendation: Merge The previous warning is resolved: Files Reviewed (1 file)
Previous review (commit eab16e4)Status: 1 Issue Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Files Reviewed (10 files)
Reviewed by glm-5.2-short · Input: 22K · Output: 4.7K · Cached: 294.7K |
Restore the pre-refactor behavior for spawn failures: print the manual cron line and continue init instead of aborting. List failures after a successful spawn still abort before any crontab write. Co-authored-by: Aanish Bhirud <baanish@users.noreply.github.com>
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b99e5f7a04
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Some(AppConfig::load_from_env_with_path(config_path.clone())) | ||
| } else { | ||
| None | ||
| }; | ||
| let needs_recreate = !config_path.exists() || existing.as_ref().is_some_and(Result::is_err); |
There was a problem hiding this comment.
Avoid recreating config on env override errors
Because load_from_env_with_path also applies QR_* overrides, any invalid override such as QR_SCAN_DEPTH=abc makes existing an Err even when config.toml itself is valid. needs_recreate then treats that as a corrupt config and prompts through a rewrite, so running qr init in that environment can overwrite a good config and still fail on the same env error when reloading; the corruption check should parse the file without env overrides or classify env errors separately.
Useful? React with 👍 / 👎.
|
|
||
| fn prompt_fallback_ai_config() -> Result<FallbackAiConfig> { | ||
| let (protocol, base_url, model, api_key, api_key_env) = prompt_provider_fields("fallback")?; | ||
| let api_key = maybe_store_key_in_keychain(protocol, &api_key_env, api_key)?; |
There was a problem hiding this comment.
Keep fallback keychain accounts distinct
This stores the fallback key with the same account derivation as the primary (api_key_env or the protocol default). When both providers use the same default, e.g. two openai-compatible endpoints with different keys, accepting the keychain prompt for the fallback overwrites the primary keychain entry; because both config api_key fields are then empty, the primary later resolves the fallback key and fails against the primary endpoint. The keychain account needs to include provider role or otherwise reject duplicate accounts when the entered secrets differ.
Useful? React with 👍 / 👎.
- Parse config.toml without QR_* overrides when deciding if init should recreate - Fail clearly on invalid env overrides instead of treating them as corrupt config - Prefix keychain accounts with primary/fallback role; legacy lookup for primary - Add tests for invalid-env init behavior and shared-default-env keychain storage Co-authored-by: Aanish Bhirud <baanish@users.noreply.github.com>
ca3787a to
c8b42a4
Compare
Summary
Combined integration of all five public-readiness workstreams:
cursor/init-secret-hardening-93e4cursor/cron-install-safety-93e4cursor/shell-wrapper-exit-status-93e4cursor/public-docs-cleanup-93e4cursor/release-metadata-hygiene-93e4Tasks 1 and 2 both touched
install_croninmain.rs; merged cleanly with the cron-safety helpers retained.Test plan
cargo test(full suite)cargo fmt --all -- --checkcargo clippy --all-targets --locked -- -D warningscargo package --locked --offlinergcheck