test: make automatic restart recovery deterministic - #152
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe fake upstream now records observed tool-call crashes. Upstream-manager tests add filesystem coordination for restart timing and verify crash observation during failed startup and automatic recovery scenarios. ChangesUpstream crash and recovery validation
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Poem
Caution Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional.
❌ Failed checks (1 error, 1 warning)
✅ Passed checks (3 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install timed out. The project may have too many dependencies for the sandbox. Comment |
|
The failed Windows Node 24 job is unrelated to #123: all core contracts passed, then the packaged-artifact contract failed in |
|
Current head
CodeRabbit is rate-limited on this head ( |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@tests/upstream-manager.test.ts`:
- Around line 520-525: Replace the fixed delay(1_100) in the restart regression
test with a bounded wait for the expected restart-count or lifecycle signal,
ensuring the retry has occurred before removing crashPath and restartGatePath.
Reuse the existing waitFor or established restart-state signal, and preserve the
subsequent cleanup sequence.
- Line 508: Update the test setup around TEST_CRASH_ON_CALL_TOOL_OBSERVED_PATH
and the recovery assertions to clear the initial crash marker after verifying
the expected first-call failure, or use a distinct marker for recovery. Ensure
the recovery toBe(false) assertion checks only whether the recovery attempt
triggered the crash fixture, while preserving the initial crashPath expectation.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 041f1e36-e04f-45ef-a100-8b476385504a
📒 Files selected for processing (2)
tests/fixtures/fake-upstream.mjstests/upstream-manager.test.ts
Dismissed under maintainer-approved CodeRabbit rate-limit exception. Both original threads are addressed in fe7394b and 6958b97; GitHub reports zero unresolved review threads. Current-head CodeRabbit re-review is Review rate limited. The exact rationale, focused validation, and local Fable boundary review are documented on this PR; real CI remains required.
|
@coderabbitai review Please run a fresh review of current head |
|
✅ Action performedReview finished.
|
Fixes #123
The automatic-restart test now gates the replacement fixture before its crash-marker preflight. It removes the crash marker before releasing the gate, proving the first retry is the recovered process and never observes stale crash state. A fixture observation marker makes the old release order deterministically reproduce restartCount 2.
Validation:
Known separate diagnostic: a full upstream-manager test-file run reproduced the existing #122 fixture-startup cascade; it is documented on #122 and is not caused by this narrow test-ordering change.
Summary by CodeRabbit