Skip to content

TEST_FAILURE_ANALYSIS.md

Latest commit

 

History

History
68 lines (49 loc) · 3.19 KB

TEST_FAILURE_ANALYSIS.md

File metadata and controls

68 lines (49 loc) · 3.19 KB

Test Failure Analysis

Summary

  • 119 tests passed ✅
  • 7 tests failed ❌

Failed Tests Analysis

1. client-end.test.ts - "ensure that file still has the same stuff in it!" (1 failure)

Status: FALSE NEGATIVE ⚠️

Issue: The test calls c.endCurrentConnection() on line 75 immediately after starting async.times(5, ...) to acquire locks. This ends the socket connection before the locks can complete, causing timeouts.

Root Cause: Test structure is incorrect - it ends the connection before operations complete.

Fix: Either:

  • Wait for locks to complete before ending connection, OR
  • Test that ending connection causes proper error handling (not timeout)

2. edge-cases.test.ts - "lock release order independence" (1 failure)

Status: POTENTIALLY REAL ISSUE ⚠️

Issue: Test acquires 5 locks on the same key 'order-test' without max option. Since it's a regular lock (not semaphore), only one lock should be acquired at a time, with others queued. The test expects all 5 to acquire, then releases in reverse order.

Root Cause:

  • If this is meant to test semaphore behavior, it should use {max: 5}
  • If this is meant to test queued locks, the test logic may be incorrect
  • Could be a real issue with lock release order affecting queued locks

Fix: Clarify test intent and fix accordingly.

3. rw-lock-edge-cases.test.ts - Multiple RW lock failures (5 failures)

Status: NEEDS INVESTIGATION 🔍

Failures:

  1. "writer blocks all readers" - Writer acquires, readers queue, writer releases after 500ms, but readers timeout
  2. "readers can coexist" - 10 readers should acquire simultaneously, but timeout
  3. "writer exclusive during readers" - Similar pattern failure
  4. "rapid read/write cycles" - Rapid cycling between read/write locks times out
  5. "write lock timeout when readers hold" - Writer should timeout when reader holds, but test times out

Possible Causes:

  1. Race conditions in tests - Callback-based tests with timing dependencies
  2. RW lock implementation issues - Problems with write-preferred RW lock logic
  3. Connection/socket issues - Problems with socket handling in RW client
  4. Timeout values too short - Tests may need longer timeouts

Investigation Needed:

  • Check if RW lock broker logic properly handles write-preferred semantics
  • Verify that readers are properly queued when writer holds lock
  • Check if socket events are properly propagated
  • Review timeout values vs actual operation times

Recommendations

  1. Fix client-end.test.ts - Restructure test to properly test connection ending
  2. Clarify edge-cases.test.ts - Determine if semaphore or queued lock test
  3. Investigate RW lock failures - These may indicate real bugs in RW lock implementation
  4. Add better error handling - Tests should provide more diagnostic info on failures
  5. Consider converting to async/await - Callback-based tests are harder to debug

Next Steps

  1. Run individual failing tests in isolation to get better error messages
  2. Add logging to RW lock operations to trace execution
  3. Review RW lock broker implementation for write-preferred logic
  4. Check if there are known issues with RW locks in the codebase