fix: cold-start persistently unreachable babysitters#179
Conversation
📝 WalkthroughWalkthroughThe change records when an unreachable babysitter session resume has been used, falls back to a durable cold start when that session remains unreachable, preserves the tracking field during cloning, expands the feature requirements, and adds end-to-end coverage. ChangesBabysitter recovery
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant IntegrationEvents
participant FactoryLoop
participant BabysitterHarness
IntegrationEvents->>FactoryLoop: Emit PR or comment event
FactoryLoop->>BabysitterHarness: Resume babysitter with continueFrom
BabysitterHarness-->>FactoryLoop: Fail integration-event wake delivery
FactoryLoop->>BabysitterHarness: Cold-start without continueFrom
Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
There was a problem hiding this comment.
Code Review
This pull request introduces a mechanism to durably cold-start a PR babysitter after a resumed session remains unreachable, preventing broken sessions from consuming slots indefinitely. It tracks whether a session has already been resumed using a dedicated recovery key stored in the state store. A new test case and harness have been added to verify this behavior. The review feedback highlights a bug where calling markResumed during a cold-start marks the recovery key as spent for the newly initialized session, which would prevent it from attempting a resume if it becomes unreachable in the future. It is recommended to clear or reset the resumed state for the recovery key when cold-starting instead.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
|
@coderabbitai review |
✅ Action performedReview finished.
|
Summary
Live failure reproduced
During the 0.1.52 production acceptance run, the local fleet registry still contained
ar-2777-babysit-cloudwhile Relay returnedagent_not_foundfor every event wake. The previous recovery path repeatedly resumed the same unaddressable session after each cooldown, leaving the lifecycle occupied without processing review feedback.This change keeps the supported no-MCP implementer fallback intact and scopes authoritative Relay recovery to babysitters, whose job requires successful event injection.
Exact-head validation (
8070aebe2b21ac6ecbe205ddf82a76537dc6a0f0)npm run buildnpm test— 69 files, 1,308 testsnpm run featuremap:check— 24 categories, 300 featuresnpm run verify:e2e— 9 packed-install checksactionlintbash -nfor repository shell scriptsgit diff --check origin/main...HEADThe PR stays unmerged until all hosted E2E workflows and review feedback are clean.
Live acceptance also exposed recursively growing recovery invocation IDs, which eventually exceeded the telemetry contract and produced
progress reporter rejected an event/ZodError. Recovery IDs now always derive from the bounded logical-agent base, and the E2E forces two cold-start generations and asserts their exact bounded shape.Hosted verification also reproduced a pre-existing PostgreSQL seed race twice:
pg_isreadyaccepted the image's temporary initialization server immediately before its intentional shutdown. The checked-in stack fixture now requires the final PID-1 PostgreSQL process before seeding, so the E2E validates the deployed server rather than relying on retries.