Fix #151: Distinguish suite-lock contention from test failure

[pseudoseed]

Summary

porch reported CHECKS FAILED when another Vitest run held the #130 suite lock, and porch next from packages/codev exited 0 with "Project not found". Contention and a wrong cwd are no longer spelled as a failed check or a silent success.

Fixes#151

Root Cause

1. acquireTestSuiteLock timed out with a generic throw. Vitest exited 1. runCheck mapped every non-zero to passed: false, so done/check/approve printed CHECKS FAILED for a suite that never ran.
2. cli() used process.cwd() as the workspace root, so a command from packages/codev could not see codev/projects. porch next printed { status: "error" } and exited 0.

Fix

• Lock wait timeout throws SuiteLockBusyError and the Vitest global setup exits 75 (EX_TEMPFAIL).
• runCheck sets blocked on exit 75 or the timeout needle. porch prints CHECKS BLOCKED, not CHECKS FAILED.
• cli() walks up to codev/projects. porch next exits 1 on status: error.

Test Plan

• Regression tests in bugfix-151-lock-contention-and-cwd.test.ts (blocked vs failed, cwd walk-up, next exit 1)
• bugfix-130 lock timeout now asserts SuiteLockBusyError / exit 75
• Build passed
• Full test suite passed (208.9s) after the lock holder finished

[pseudoseed]

APPROVED

The core fix is exactly right: lock contention gets its own outcome.SUITE_LOCK_BUSY_EXIT = 75 (EX_TEMPFAIL) is distinct from a test failure's 1, runCheck marks the check blocked rather than failed, and porch prints CHECKS BLOCKED instead of CHECKS FAILED.

That matters because CHECKS FAILED is how porch reports a real defect. Spelling "I could not run the tests" the same way sent spir-146 hunting a bug that did not exist — twice today — and cost about 200s of suite time each round. Worse, it trains re-running until green, which is the habit that eventually lets a genuine intermittent failure through.

Putting SUITE_LOCK_BUSY_EXIT and SUITE_LOCK_TIMEOUT_NEEDLE in a shared lib/suite-lock.ts, imported by both vitest-global-setup.ts and porch's checks, is the right structure. The contract between the two sides is now one definition rather than a magic number and a string repeated in two places that can drift.

The bonus find is a real one

porch next 151 → { status: "error", error: "Project 151 not found..." }exit 0

A porch command reporting an error and exiting 0 is the same defect class this repo keeps surfacing: a failure indistinguishable from success to anything reading the exit code, which is what scripts and CI read. Fixing porch next to exit 1 on status: error was not in the issue and is worth more than the line count suggests.

Non-blocking

The issue asked for the holder to be named — which workspace and builder hold the lock — so the message points at the cause rather than at whoever asked next. That is not in this PR. The distinct outcome is the part that matters and it is here; naming the holder can follow. Worth a line in the issue so it is not lost rather than silently dropped.

Provenance

This PR's CMAP ran before #187 merged, so those three lanes still had write access. I checked the worktree: zero tracked modifications, so nothing was contaminated. #187 is now on main at 86ea4a2d2, and lanes are read-only from here.

[pseudoseed]

Summary

porch reported CHECKS FAILED when another Vitest run held the #130 suite lock, and porch next from packages/codev exited 0 with "Project not found". Contention and a wrong cwd are no longer spelled as a failed check or a silent success.

Fixes#151

Root Cause

1. acquireTestSuiteLock timed out with a generic throw. Vitest exited 1. runCheck mapped every non-zero to passed: false, so done/check/approve printed CHECKS FAILED for a suite that never ran.
2. cli() used process.cwd() as the workspace root, so a command from packages/codev could not see codev/projects. porch next printed { status: "error" } and exited 0.

Fix

• Lock wait timeout throws SuiteLockBusyError and the Vitest global setup exits 75 (EX_TEMPFAIL).
• runCheck sets blocked on exit 75 or the timeout needle. porch prints CHECKS BLOCKED, not CHECKS FAILED.
• cli() walks up to codev/projects. porch next exits 1 on status: error.

Test Plan

• Regression tests in bugfix-151-lock-contention-and-cwd.test.ts (blocked vs failed, cwd walk-up, next exit 1)
• bugfix-130 lock timeout now asserts SuiteLockBusyError / exit 75
• Build passed
• Full test suite passed (208.9s) after the lock holder finished

[pseudoseed]

APPROVED

The core fix is exactly right: lock contention gets its own outcome.SUITE_LOCK_BUSY_EXIT = 75 (EX_TEMPFAIL) is distinct from a test failure's 1, runCheck marks the check blocked rather than failed, and porch prints CHECKS BLOCKED instead of CHECKS FAILED.

That matters because CHECKS FAILED is how porch reports a real defect. Spelling "I could not run the tests" the same way sent spir-146 hunting a bug that did not exist — twice today — and cost about 200s of suite time each round. Worse, it trains re-running until green, which is the habit that eventually lets a genuine intermittent failure through.

Putting SUITE_LOCK_BUSY_EXIT and SUITE_LOCK_TIMEOUT_NEEDLE in a shared lib/suite-lock.ts, imported by both vitest-global-setup.ts and porch's checks, is the right structure. The contract between the two sides is now one definition rather than a magic number and a string repeated in two places that can drift.

The bonus find is a real one

porch next 151 → { status: "error", error: "Project 151 not found..." }exit 0

A porch command reporting an error and exiting 0 is the same defect class this repo keeps surfacing: a failure indistinguishable from success to anything reading the exit code, which is what scripts and CI read. Fixing porch next to exit 1 on status: error was not in the issue and is worth more than the line count suggests.

Non-blocking

The issue asked for the holder to be named — which workspace and builder hold the lock — so the message points at the cause rather than at whoever asked next. That is not in this PR. The distinct outcome is the part that matters and it is here; naming the holder can follow. Worth a line in the issue so it is not lost rather than silently dropped.

Provenance

This PR's CMAP ran before #187 merged, so those three lanes still had write access. I checked the worktree: zero tracked modifications, so nothing was contaminated. #187 is now on main at 86ea4a2d2, and lanes are read-only from here.

[pseudoseed]

Summary

porch reported CHECKS FAILED when another Vitest run held the #130 suite lock, and porch next from packages/codev exited 0 with "Project not found". Contention and a wrong cwd are no longer spelled as a failed check or a silent success.

Fixes#151

Root Cause

1. acquireTestSuiteLock timed out with a generic throw. Vitest exited 1. runCheck mapped every non-zero to passed: false, so done/check/approve printed CHECKS FAILED for a suite that never ran.
2. cli() used process.cwd() as the workspace root, so a command from packages/codev could not see codev/projects. porch next printed { status: "error" } and exited 0.

Fix

• Lock wait timeout throws SuiteLockBusyError and the Vitest global setup exits 75 (EX_TEMPFAIL).
• runCheck sets blocked on exit 75 or the timeout needle. porch prints CHECKS BLOCKED, not CHECKS FAILED.
• cli() walks up to codev/projects. porch next exits 1 on status: error.

Test Plan

• Regression tests in bugfix-151-lock-contention-and-cwd.test.ts (blocked vs failed, cwd walk-up, next exit 1)
• bugfix-130 lock timeout now asserts SuiteLockBusyError / exit 75
• Build passed
• Full test suite passed (208.9s) after the lock holder finished

[pseudoseed]

APPROVED

The core fix is exactly right: lock contention gets its own outcome.SUITE_LOCK_BUSY_EXIT = 75 (EX_TEMPFAIL) is distinct from a test failure's 1, runCheck marks the check blocked rather than failed, and porch prints CHECKS BLOCKED instead of CHECKS FAILED.

That matters because CHECKS FAILED is how porch reports a real defect. Spelling "I could not run the tests" the same way sent spir-146 hunting a bug that did not exist — twice today — and cost about 200s of suite time each round. Worse, it trains re-running until green, which is the habit that eventually lets a genuine intermittent failure through.

Putting SUITE_LOCK_BUSY_EXIT and SUITE_LOCK_TIMEOUT_NEEDLE in a shared lib/suite-lock.ts, imported by both vitest-global-setup.ts and porch's checks, is the right structure. The contract between the two sides is now one definition rather than a magic number and a string repeated in two places that can drift.

The bonus find is a real one

porch next 151 → { status: "error", error: "Project 151 not found..." }exit 0

A porch command reporting an error and exiting 0 is the same defect class this repo keeps surfacing: a failure indistinguishable from success to anything reading the exit code, which is what scripts and CI read. Fixing porch next to exit 1 on status: error was not in the issue and is worth more than the line count suggests.

Non-blocking

The issue asked for the holder to be named — which workspace and builder hold the lock — so the message points at the cause rather than at whoever asked next. That is not in this PR. The distinct outcome is the part that matters and it is here; naming the holder can follow. Worth a line in the issue so it is not lost rather than silently dropped.

Provenance

This PR's CMAP ran before #187 merged, so those three lanes still had write access. I checked the worktree: zero tracked modifications, so nothing was contaminated. #187 is now on main at 86ea4a2d2, and lanes are read-only from here.

[pseudoseed]

Summary

porch reported CHECKS FAILED when another Vitest run held the #130 suite lock, and porch next from packages/codev exited 0 with "Project not found". Contention and a wrong cwd are no longer spelled as a failed check or a silent success.

Fixes#151

Root Cause

1. acquireTestSuiteLock timed out with a generic throw. Vitest exited 1. runCheck mapped every non-zero to passed: false, so done/check/approve printed CHECKS FAILED for a suite that never ran.
2. cli() used process.cwd() as the workspace root, so a command from packages/codev could not see codev/projects. porch next printed { status: "error" } and exited 0.

Fix

• Lock wait timeout throws SuiteLockBusyError and the Vitest global setup exits 75 (EX_TEMPFAIL).
• runCheck sets blocked on exit 75 or the timeout needle. porch prints CHECKS BLOCKED, not CHECKS FAILED.
• cli() walks up to codev/projects. porch next exits 1 on status: error.

Test Plan

• Regression tests in bugfix-151-lock-contention-and-cwd.test.ts (blocked vs failed, cwd walk-up, next exit 1)
• bugfix-130 lock timeout now asserts SuiteLockBusyError / exit 75
• Build passed
• Full test suite passed (208.9s) after the lock holder finished

[pseudoseed]

APPROVED

The core fix is exactly right: lock contention gets its own outcome.SUITE_LOCK_BUSY_EXIT = 75 (EX_TEMPFAIL) is distinct from a test failure's 1, runCheck marks the check blocked rather than failed, and porch prints CHECKS BLOCKED instead of CHECKS FAILED.

That matters because CHECKS FAILED is how porch reports a real defect. Spelling "I could not run the tests" the same way sent spir-146 hunting a bug that did not exist — twice today — and cost about 200s of suite time each round. Worse, it trains re-running until green, which is the habit that eventually lets a genuine intermittent failure through.

Putting SUITE_LOCK_BUSY_EXIT and SUITE_LOCK_TIMEOUT_NEEDLE in a shared lib/suite-lock.ts, imported by both vitest-global-setup.ts and porch's checks, is the right structure. The contract between the two sides is now one definition rather than a magic number and a string repeated in two places that can drift.

The bonus find is a real one

porch next 151 → { status: "error", error: "Project 151 not found..." }exit 0

A porch command reporting an error and exiting 0 is the same defect class this repo keeps surfacing: a failure indistinguishable from success to anything reading the exit code, which is what scripts and CI read. Fixing porch next to exit 1 on status: error was not in the issue and is worth more than the line count suggests.

Non-blocking

The issue asked for the holder to be named — which workspace and builder hold the lock — so the message points at the cause rather than at whoever asked next. That is not in this PR. The distinct outcome is the part that matters and it is here; naming the holder can follow. Worth a line in the issue so it is not lost rather than silently dropped.

Provenance

This PR's CMAP ran before #187 merged, so those three lanes still had write access. I checked the worktree: zero tracked modifications, so nothing was contaminated. #187 is now on main at 86ea4a2d2, and lanes are read-only from here.

[pseudoseed]

Summary

porch reported CHECKS FAILED when another Vitest run held the #130 suite lock, and porch next from packages/codev exited 0 with "Project not found". Contention and a wrong cwd are no longer spelled as a failed check or a silent success.

Fixes#151

Root Cause

1. acquireTestSuiteLock timed out with a generic throw. Vitest exited 1. runCheck mapped every non-zero to passed: false, so done/check/approve printed CHECKS FAILED for a suite that never ran.
2. cli() used process.cwd() as the workspace root, so a command from packages/codev could not see codev/projects. porch next printed { status: "error" } and exited 0.

Fix

• Lock wait timeout throws SuiteLockBusyError and the Vitest global setup exits 75 (EX_TEMPFAIL).
• runCheck sets blocked on exit 75 or the timeout needle. porch prints CHECKS BLOCKED, not CHECKS FAILED.
• cli() walks up to codev/projects. porch next exits 1 on status: error.

Test Plan

• Regression tests in bugfix-151-lock-contention-and-cwd.test.ts (blocked vs failed, cwd walk-up, next exit 1)
• bugfix-130 lock timeout now asserts SuiteLockBusyError / exit 75
• Build passed
• Full test suite passed (208.9s) after the lock holder finished

[pseudoseed]

APPROVED

The core fix is exactly right: lock contention gets its own outcome.SUITE_LOCK_BUSY_EXIT = 75 (EX_TEMPFAIL) is distinct from a test failure's 1, runCheck marks the check blocked rather than failed, and porch prints CHECKS BLOCKED instead of CHECKS FAILED.

That matters because CHECKS FAILED is how porch reports a real defect. Spelling "I could not run the tests" the same way sent spir-146 hunting a bug that did not exist — twice today — and cost about 200s of suite time each round. Worse, it trains re-running until green, which is the habit that eventually lets a genuine intermittent failure through.

Putting SUITE_LOCK_BUSY_EXIT and SUITE_LOCK_TIMEOUT_NEEDLE in a shared lib/suite-lock.ts, imported by both vitest-global-setup.ts and porch's checks, is the right structure. The contract between the two sides is now one definition rather than a magic number and a string repeated in two places that can drift.

The bonus find is a real one

porch next 151 → { status: "error", error: "Project 151 not found..." }exit 0

A porch command reporting an error and exiting 0 is the same defect class this repo keeps surfacing: a failure indistinguishable from success to anything reading the exit code, which is what scripts and CI read. Fixing porch next to exit 1 on status: error was not in the issue and is worth more than the line count suggests.

Non-blocking

The issue asked for the holder to be named — which workspace and builder hold the lock — so the message points at the cause rather than at whoever asked next. That is not in this PR. The distinct outcome is the part that matters and it is here; naming the holder can follow. Worth a line in the issue so it is not lost rather than silently dropped.

Provenance

This PR's CMAP ran before #187 merged, so those three lanes still had write access. I checked the worktree: zero tracked modifications, so nothing was contaminated. #187 is now on main at 86ea4a2d2, and lanes are read-only from here.

[pseudoseed]

Summary

porch reported CHECKS FAILED when another Vitest run held the #130 suite lock, and porch next from packages/codev exited 0 with "Project not found". Contention and a wrong cwd are no longer spelled as a failed check or a silent success.

Fixes#151

Root Cause

1. acquireTestSuiteLock timed out with a generic throw. Vitest exited 1. runCheck mapped every non-zero to passed: false, so done/check/approve printed CHECKS FAILED for a suite that never ran.
2. cli() used process.cwd() as the workspace root, so a command from packages/codev could not see codev/projects. porch next printed { status: "error" } and exited 0.

Fix

• Lock wait timeout throws SuiteLockBusyError and the Vitest global setup exits 75 (EX_TEMPFAIL).
• runCheck sets blocked on exit 75 or the timeout needle. porch prints CHECKS BLOCKED, not CHECKS FAILED.
• cli() walks up to codev/projects. porch next exits 1 on status: error.

Test Plan

• Regression tests in bugfix-151-lock-contention-and-cwd.test.ts (blocked vs failed, cwd walk-up, next exit 1)
• bugfix-130 lock timeout now asserts SuiteLockBusyError / exit 75
• Build passed
• Full test suite passed (208.9s) after the lock holder finished

[pseudoseed]

APPROVED

The core fix is exactly right: lock contention gets its own outcome.SUITE_LOCK_BUSY_EXIT = 75 (EX_TEMPFAIL) is distinct from a test failure's 1, runCheck marks the check blocked rather than failed, and porch prints CHECKS BLOCKED instead of CHECKS FAILED.

That matters because CHECKS FAILED is how porch reports a real defect. Spelling "I could not run the tests" the same way sent spir-146 hunting a bug that did not exist — twice today — and cost about 200s of suite time each round. Worse, it trains re-running until green, which is the habit that eventually lets a genuine intermittent failure through.

Putting SUITE_LOCK_BUSY_EXIT and SUITE_LOCK_TIMEOUT_NEEDLE in a shared lib/suite-lock.ts, imported by both vitest-global-setup.ts and porch's checks, is the right structure. The contract between the two sides is now one definition rather than a magic number and a string repeated in two places that can drift.

The bonus find is a real one

porch next 151 → { status: "error", error: "Project 151 not found..." }exit 0

A porch command reporting an error and exiting 0 is the same defect class this repo keeps surfacing: a failure indistinguishable from success to anything reading the exit code, which is what scripts and CI read. Fixing porch next to exit 1 on status: error was not in the issue and is worth more than the line count suggests.

Non-blocking

The issue asked for the holder to be named — which workspace and builder hold the lock — so the message points at the cause rather than at whoever asked next. That is not in this PR. The distinct outcome is the part that matters and it is here; naming the holder can follow. Worth a line in the issue so it is not lost rather than silently dropped.

Provenance

This PR's CMAP ran before #187 merged, so those three lanes still had write access. I checked the worktree: zero tracked modifications, so nothing was contaminated. #187 is now on main at 86ea4a2d2, and lanes are read-only from here.

[pseudoseed]

Summary

porch reported CHECKS FAILED when another Vitest run held the #130 suite lock, and porch next from packages/codev exited 0 with "Project not found". Contention and a wrong cwd are no longer spelled as a failed check or a silent success.

Fixes#151

Root Cause

1. acquireTestSuiteLock timed out with a generic throw. Vitest exited 1. runCheck mapped every non-zero to passed: false, so done/check/approve printed CHECKS FAILED for a suite that never ran.
2. cli() used process.cwd() as the workspace root, so a command from packages/codev could not see codev/projects. porch next printed { status: "error" } and exited 0.

Fix

• Lock wait timeout throws SuiteLockBusyError and the Vitest global setup exits 75 (EX_TEMPFAIL).
• runCheck sets blocked on exit 75 or the timeout needle. porch prints CHECKS BLOCKED, not CHECKS FAILED.
• cli() walks up to codev/projects. porch next exits 1 on status: error.

Test Plan

• Regression tests in bugfix-151-lock-contention-and-cwd.test.ts (blocked vs failed, cwd walk-up, next exit 1)
• bugfix-130 lock timeout now asserts SuiteLockBusyError / exit 75
• Build passed
• Full test suite passed (208.9s) after the lock holder finished

[pseudoseed]

APPROVED

The core fix is exactly right: lock contention gets its own outcome.SUITE_LOCK_BUSY_EXIT = 75 (EX_TEMPFAIL) is distinct from a test failure's 1, runCheck marks the check blocked rather than failed, and porch prints CHECKS BLOCKED instead of CHECKS FAILED.

That matters because CHECKS FAILED is how porch reports a real defect. Spelling "I could not run the tests" the same way sent spir-146 hunting a bug that did not exist — twice today — and cost about 200s of suite time each round. Worse, it trains re-running until green, which is the habit that eventually lets a genuine intermittent failure through.

Putting SUITE_LOCK_BUSY_EXIT and SUITE_LOCK_TIMEOUT_NEEDLE in a shared lib/suite-lock.ts, imported by both vitest-global-setup.ts and porch's checks, is the right structure. The contract between the two sides is now one definition rather than a magic number and a string repeated in two places that can drift.

The bonus find is a real one

porch next 151 → { status: "error", error: "Project 151 not found..." }exit 0

A porch command reporting an error and exiting 0 is the same defect class this repo keeps surfacing: a failure indistinguishable from success to anything reading the exit code, which is what scripts and CI read. Fixing porch next to exit 1 on status: error was not in the issue and is worth more than the line count suggests.

Non-blocking

The issue asked for the holder to be named — which workspace and builder hold the lock — so the message points at the cause rather than at whoever asked next. That is not in this PR. The distinct outcome is the part that matters and it is here; naming the holder can follow. Worth a line in the issue so it is not lost rather than silently dropped.

Provenance

This PR's CMAP ran before #187 merged, so those three lanes still had write access. I checked the worktree: zero tracked modifications, so nothing was contaminated. #187 is now on main at 86ea4a2d2, and lanes are read-only from here.

[pseudoseed]

Summary

porch reported CHECKS FAILED when another Vitest run held the #130 suite lock, and porch next from packages/codev exited 0 with "Project not found". Contention and a wrong cwd are no longer spelled as a failed check or a silent success.

Fixes#151

Root Cause

1. acquireTestSuiteLock timed out with a generic throw. Vitest exited 1. runCheck mapped every non-zero to passed: false, so done/check/approve printed CHECKS FAILED for a suite that never ran.
2. cli() used process.cwd() as the workspace root, so a command from packages/codev could not see codev/projects. porch next printed { status: "error" } and exited 0.

Fix

• Lock wait timeout throws SuiteLockBusyError and the Vitest global setup exits 75 (EX_TEMPFAIL).
• runCheck sets blocked on exit 75 or the timeout needle. porch prints CHECKS BLOCKED, not CHECKS FAILED.
• cli() walks up to codev/projects. porch next exits 1 on status: error.

Test Plan

• Regression tests in bugfix-151-lock-contention-and-cwd.test.ts (blocked vs failed, cwd walk-up, next exit 1)
• bugfix-130 lock timeout now asserts SuiteLockBusyError / exit 75
• Build passed
• Full test suite passed (208.9s) after the lock holder finished

[pseudoseed]

APPROVED

The core fix is exactly right: lock contention gets its own outcome.SUITE_LOCK_BUSY_EXIT = 75 (EX_TEMPFAIL) is distinct from a test failure's 1, runCheck marks the check blocked rather than failed, and porch prints CHECKS BLOCKED instead of CHECKS FAILED.

That matters because CHECKS FAILED is how porch reports a real defect. Spelling "I could not run the tests" the same way sent spir-146 hunting a bug that did not exist — twice today — and cost about 200s of suite time each round. Worse, it trains re-running until green, which is the habit that eventually lets a genuine intermittent failure through.

Putting SUITE_LOCK_BUSY_EXIT and SUITE_LOCK_TIMEOUT_NEEDLE in a shared lib/suite-lock.ts, imported by both vitest-global-setup.ts and porch's checks, is the right structure. The contract between the two sides is now one definition rather than a magic number and a string repeated in two places that can drift.

The bonus find is a real one

porch next 151 → { status: "error", error: "Project 151 not found..." }exit 0

A porch command reporting an error and exiting 0 is the same defect class this repo keeps surfacing: a failure indistinguishable from success to anything reading the exit code, which is what scripts and CI read. Fixing porch next to exit 1 on status: error was not in the issue and is worth more than the line count suggests.

Non-blocking

The issue asked for the holder to be named — which workspace and builder hold the lock — so the message points at the cause rather than at whoever asked next. That is not in this PR. The distinct outcome is the part that matters and it is here; naming the holder can follow. Worth a line in the issue so it is not lost rather than silently dropped.

Provenance

This PR's CMAP ran before #187 merged, so those three lanes still had write access. I checked the worktree: zero tracked modifications, so nothing was contaminated. #187 is now on main at 86ea4a2d2, and lanes are read-only from here.