feat: Add --await flag to enable-pause-point for single-command enable and wait#1893
Conversation
Previously enabling a marker and waiting for it required two separate CLI invocations, which raced against fast-progressing games between the two calls. --await lets the CLI enable the marker and, only on a successful enable, chain into the existing await-pause-point poll loop within the same process. Unity still sees exactly the same two IPC calls (enable, then poll) as manual two-step usage, and the non-awaiting path is byte-for-byte the pre-existing generic schema dispatch. --captured-variables/--captured-variable-names are also accepted when --await is set, mirroring await-pause-point.
…rding The template now enables and waits for a marker in one backgrounded call via --await instead of three separate enable/trigger/await invocations, and notes that single-shot markers need no clear call. Also corrects a Fast-Progressing Games line added in a prior change that referenced a nonexistent control-play-mode "Resume" action; the only actions are Play/Stop/Pause/Step, so resuming is phrased as `control-play-mode --action Play`.
|
Warning Review limit reached
Next review available in: 2 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: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (9)
✨ 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 |
…e-pause-point --await Address 3 final-review findings: apply debug-timing instrumentation before the enable send so --await gets the same ULOOP_DEBUG timing info as the plain enable path; report the correct command name (enable-pause-point, not await-pause-point) on wait errors raised through --await; and fix a dangling clause in the Quick Check Template describing when clear-pause-point is still needed for a disarmed single-shot marker.
ab3e753
into
feature/pause-point-round4-integration
Summary
enable-pause-point --awaitenables a marker and waits for the hit (or timeout) in one call, instead of requiring a separateawait-pause-pointinvocation.User Impact
enable-pause-point, a trigger command, then a separateawait-pause-point. With--await, the enable call itself waits for the hit, so the workflow only needs the enable-and-wait call (run in the background) plus the trigger.--captured-variables/--captured-variable-namesare now accepted onenable-pause-pointas well, mirroringawait-pause-point, and only take effect together with--await.single-shotmarker (the default) is now documented as not needing aclear-pause-pointcall, since it already disarms itself after the hit.control-play-mode"Resume" action; the real actions are Play/Stop/Pause/Step, so the text now says to resume withcontrol-play-mode --action Play.Changes
enable-pause-pointwithout--awaitis unchanged: same schema-driven dispatch, same single IPC call, same response shape.--await, the CLI sends the same singleenable-pause-pointIPC request as before; only on a successful enable does it reuse the existingawait-pause-pointpoll loop (get-pause-point-status) in-process. Unity never sees an extra or different IPC call for--await.Warning(for example the physics-callback cached-dispatch warning) is preserved and merged into the final response when--awaitwaits through to a hit.--await/--captured-variables/--captured-variable-namesare CLI-only flags, stripped before the existing schema-driven parameter builder runs, so they never reach Unity'sEnablePausePointSchema.cli/commonchanges:enable-pause-pointkeeps its existing schema-tool identity: it is not added toclicore.NativeCommands, avoiding a second, conflicting command identity (double help listing, different tool-settings gating path).Verification
scripts/check-go-cli.sh: all packages pass (fmt/vet/lint/test/build)--awaitalone, with captured-variable options, missing--awaitguard, unrelated args untouched), a full enable-then-hit round trip against a fake Unity IPC listener, a failed-enable-skips-wait case, and auloop listcatalog test for the new optionsenable-pause-pointwithout--await(unchanged response),enable-pause-point --awaitwith an already-expired marker (correctPAUSE_POINT_EXPIREDdiagnosis), and the--captured-variableswithout--awaitrejectionuloop skills install --claude --agents: regenerated copies verified byte-identical to source