Is there an existing issue for the same bug?
Branch Name
main
Commit ID
b605abfe6475fbe7ffa49cd6d4d1184fc1bda8b5
Other Environment Information
- Hardware parameters: GitHub-hosted Ubuntu x86 runner
- OS type: Ubuntu
- Others:
MatrixOne ALL CI, race-enabled resource-heavy UT group, workflow run 33073484041 attempt 1
Actual Behavior
The Ubuntu full-UT job intermittently fails pkg/fileservice/TestDiskCacheAsyncCallbacksRemainOrderedAndBounded at disk_cache_lifecycle_test.go:721:
Error: Received unexpected error:
context deadline exceeded
Test: TestDiskCacheAsyncCallbacksRemainOrderedAndBounded
--- FAIL: TestDiskCacheAsyncCallbacksRemainOrderedAndBounded (5.38s)
The test submits 64 asynchronous cache updates, blocks their callbacks, and then requires cache.Flush to drain the writes within the shared fixed five-second lifecycle-test timeout. Under the resource-heavy race shard, the pending writes did not drain before that performance deadline.
The callbacks are intentionally outside the Flush completion barrier, so the product contract is not the source of the failure. The test lacks deterministic observability for the write-drained phase and uses elapsed wall-clock time as its only completion proof.
Expected Behavior
The lifecycle test should deterministically prove that all pending writes have drained while callbacks remain blocked. Scheduler load should not decide whether the test passes. The fix should use an observable synchronization phase or deterministic test control rather than increasing the timeout or adding sleeps.
Steps to Reproduce
1. Run the race-enabled MatrixOne full UT suite in the resource-heavy package group.
2. Let TestDiskCacheAsyncCallbacksRemainOrderedAndBounded submit cap(cache.async.slots) (64) updates.
3. Under sufficient runner contention, cache.Flush reaches its five-second context deadline before all writes drain.
Observed in:
Additional information
- The job reported this as the sole failed UT case; the
pkg/fileservice package took 223.16 seconds and this test failed after 5.38 seconds.
- The same-head coverage UT producer passed.
- Exact-head focused race validation passed once and then 100/100 repetitions locally (
go test -short -race -count=100 -run '^TestDiskCacheAsyncCallbacksRemainOrderedAndBounded$' ./pkg/fileservice, package elapsed 11.139 seconds), which supports a load-sensitive timing failure rather than a deterministic functional regression.
- The triggering PR changes only
pkg/frontend/snapshot.go and pkg/tests/issues/issue_27718_test.go; it does not touch pkg/fileservice or this synchronization path.
Is there an existing issue for the same bug?
Branch Name
main
Commit ID
b605abfe6475fbe7ffa49cd6d4d1184fc1bda8b5Other Environment Information
MatrixOne ALL CI, race-enabled resource-heavy UT group, workflow run 33073484041 attempt 1Actual Behavior
The Ubuntu full-UT job intermittently fails
pkg/fileservice/TestDiskCacheAsyncCallbacksRemainOrderedAndBoundedatdisk_cache_lifecycle_test.go:721:The test submits 64 asynchronous cache updates, blocks their callbacks, and then requires
cache.Flushto drain the writes within the shared fixed five-second lifecycle-test timeout. Under the resource-heavy race shard, the pending writes did not drain before that performance deadline.The callbacks are intentionally outside the
Flushcompletion barrier, so the product contract is not the source of the failure. The test lacks deterministic observability for the write-drained phase and uses elapsed wall-clock time as its only completion proof.Expected Behavior
The lifecycle test should deterministically prove that all pending writes have drained while callbacks remain blocked. Scheduler load should not decide whether the test passes. The fix should use an observable synchronization phase or deterministic test control rather than increasing the timeout or adding sleeps.
Steps to Reproduce
Observed in:
Additional information
pkg/fileservicepackage took 223.16 seconds and this test failed after 5.38 seconds.go test -short -race -count=100 -run '^TestDiskCacheAsyncCallbacksRemainOrderedAndBounded$' ./pkg/fileservice, package elapsed 11.139 seconds), which supports a load-sensitive timing failure rather than a deterministic functional regression.pkg/frontend/snapshot.goandpkg/tests/issues/issue_27718_test.go; it does not touchpkg/fileserviceor this synchronization path.