Description

In LockStepReserveInsideLockHonouredTest, there's a race condition where parallel stage p2 can call lr.reserve('test2-1') before parallel stage p1 logs point 1-5, causing the test assertion Locked resource reservedBy 1-5: null to fail.

The test currently tolerates this by catching the assertion error and accepting test2-1 as an alternative value, but this masks a potential real bug in the reservation handling.

Expected Behavior

When p1 calls lrm.unreserve([lr]) and then logs the reservation state at point 1-5, it should consistently see null because the unreserve happened in p1's flow before the logging.

Actual Behavior

Sometimes p2 acquires the lock and calls lr.reserve('test2-1') between:

1. p1's unreserve() call
2. p1's logging of the 1-5 state

This suggests there may be a synchronization gap where the resource state appears inconsistent across parallel stages.

Code Location

• Test: LockStepReserveInsideLockHonouredTest.java:217-241
• The workaround tolerates both null and test2-1 as valid states

Impact

• Test flakiness (test fails randomly depending on thread timing)
• Potential production issue where reservation state is inconsistent

Related

This was discovered while investigating CI timeout issues on master branch.