t1452: enforce pulse dispatch launch validation and CLI guardrails#4193
t1452: enforce pulse dispatch launch validation and CLI guardrails#4193marcusquinn merged 1 commit intomainfrom
Conversation
Summary of ChangesHello, 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 addresses the issue of false-positive dispatches in recent pulse cycles, where workers were incorrectly considered launched despite startup logs indicating Highlights
Changelog
Activity
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
|
WalkthroughThe pull request adds post-dispatch validation instructions to the pulse agent documentation. After each worker dispatch, validation checks that the process is live and startup logs do not contain CLI usage output, triggering immediate relaunch via the headless helper if validation fails. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
🔍 Code Quality Report�[0;35m[MONITOR]�[0m Code Review Monitoring Report �[0;34m[INFO]�[0m Latest Quality Status: �[0;34m[INFO]�[0m Recent monitoring activity: 📈 Current Quality Metrics
Generated on: Thu Mar 12 01:02:23 UTC 2026 Generated by AI DevOps Framework Code Review Monitoring |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the pulse.md documentation to enforce launch validation for dispatched workers. It adds a new mandatory validation step with a code snippet to check for running processes and invalid log output. It also adds guardrails against using unsupported flags with opencode run. The changes are clear and align with the goal of preventing false-positive dispatches. I have one suggestion to simplify a command in the documentation for better clarity.
|
|
||
| ```bash | ||
| # 1) Process exists (session-key must map to a live run) | ||
| pgrep -fal "issue-<number>|Issue #<number>:" >/dev/null |
There was a problem hiding this comment.
The pgrep command can be simplified. The -a (show full command line) and -l (show process name) flags are used for display purposes, but since the output is redirected to /dev/null, they are unnecessary. Using only the -f flag is sufficient to check for the process's existence via its exit code and is more idiomatic.
| pgrep -fal "issue-<number>|Issue #<number>:" >/dev/null | |
| pgrep -f "issue-<number>|Issue #<number>:" >/dev/null |
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.agents/scripts/commands/pulse.md:
- Around line 563-575: The pulse script's current startup validation wrongly
inspects a /tmp log (LOG_PATH) that headless-runtime-helper.sh does not leave
behind; replace this ad-hoc file check with the helper's deterministic
launch-validation contract: call headless-runtime-helper.sh run (or its
dedicated validate/launch subcommand) and consume its explicit exit status or
emitted validation result/JSON rather than grepping LOG_PATH, then on failure
immediately re-dispatch via headless-runtime-helper.sh run and post the short
issue comment; update references in pulse to use the helper's validation output
(instead of LOG_PATH/rg) and adjust the relaunch logic to rely on the helper's
success/failure signal.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 75c20ceb-f75c-4c8c-bcac-5fb181e8bcaf
📒 Files selected for processing (1)
.agents/scripts/commands/pulse.md
| ```bash | ||
| # 1) Process exists (session-key must map to a live run) | ||
| pgrep -fal "issue-<number>|Issue #<number>:" >/dev/null | ||
|
|
||
| # 2) Startup log is not CLI help/usage output | ||
| LOG_PATH="/tmp/pulse-<slug>-<number>.log" | ||
| if [[ -f "$LOG_PATH" ]] && rg -q '^opencode run \[message\.\.]|^run opencode with a message|^Options:' "$LOG_PATH"; then | ||
| echo "Invalid worker launch for #<number> (CLI usage output)" | ||
| # Relaunch immediately via helper (never leave this for next pulse) | ||
| fi | ||
| ``` | ||
|
|
||
| If validation fails, re-dispatch immediately via `headless-runtime-helper.sh run`, add a short issue comment noting the failed launch and correction, and continue filling slots. |
There was a problem hiding this comment.
Use the helper’s real launch contract here, not an invented /tmp log file.
headless-runtime-helper.sh run does not write startup output to /tmp/pulse-<slug>-<number>.log; it captures to a temp file internally, validates activity, and deletes that file before returning. As written, this “mandatory” check will usually no-op on the log check and miss the exact usage-output false starts from #4192. Please move this to the deterministic helper/check path the issue calls for, or have the helper emit a launch-validation result that pulse can consume directly.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.agents/scripts/commands/pulse.md around lines 563 - 575, The pulse script's
current startup validation wrongly inspects a /tmp log (LOG_PATH) that
headless-runtime-helper.sh does not leave behind; replace this ad-hoc file check
with the helper's deterministic launch-validation contract: call
headless-runtime-helper.sh run (or its dedicated validate/launch subcommand) and
consume its explicit exit status or emitted validation result/JSON rather than
grepping LOG_PATH, then on failure immediately re-dispatch via
headless-runtime-helper.sh run and post the short issue comment; update
references in pulse to use the helper's validation output (instead of
LOG_PATH/rg) and adjust the relaunch logic to rely on the helper's
success/failure signal.
1 participant
Summary
opencode runflags (notably--max-iterations) when doing diagnostic dispatchesRoot Cause Addressed
Recent pulse cycles showed false-positive dispatches where workers were considered launched but startup logs contained
opencode runusage output. This caused slot waste and delayed throughput recovery.Verification
markdown-formatter check .agents/scripts/commands/pulse.mdCloses #4192
Summary by CodeRabbit