-
Type:
Improvement
-
Resolution: Fixed
-
Priority:
Minor - P4
-
Affects Version/s: None
-
Component/s: Test Python
-
None
-
Storage Engines, Storage Engines - Persistence
-
161.364
-
SE Persistence backlog
-
None
Issue Summary
Follow-up to [WT-18411], which found that test_key_provider_disagg02 could not detect whether its checkpoint crash points fired. A sweep of test/suite for the same defect class turned up two more tests worth hardening.
test_bug018 (the real gap)
The test simulates a write failure by closing WiredTiger's file descriptor for the second table out from underneath it, then checks that both tables come back in sync after recovery. It discards the subprocess exit status, and its only assertion is assertEqual(results1, results2). If the descriptor trick ever stops simulating the failure - the loop over /proc/self/fd simply finds no match - both tables recover intact, the two result lists match, and the test passes having exercised nothing. It already tolerates rather than requires the failure signal, via ignoreStdoutPattern('log_slot_destroy: failed to write slot').
Suggested fix: require the write failure to have happened, either by asserting the subprocess exit status or by promoting the ignored stdout pattern to an expected one.
Note the test is Linux only (setUp skips elsewhere), so this needs CI or a Linux host to verify.
test_schema09 (hardening only)
Verified this one does currently detect a dead crash point: neutralising __wti_debug_crash_if_flag_set in src/schema/schema_util.c fails all four scenarios on the expected "removing incomplete table" stdout pattern. Two fragilities:
* It passes no scenario= to run_subprocess_function. That is harmless only because each scenario dispatches to a differently named subprocess_crash_point_* method that hardcodes its own crash point. Making the crash point scenario driven, as test_key_provider_disagg02 does, would silently regress it to testing scenario 0 four times.
* For the after_drop_file and after_drop_colgroup scenarios the metadata assertions hold either way, since a completed drop leaves the same absent entries as a crashed one. The stdout pattern is the only thing covering those two.
Suggested fix: assert the subprocess exit status, using the same portable helper as [WT-18411].
Definition of Done
* test_bug018 fails if the simulated write failure does not occur.
* test_schema09 asserts the subprocess was killed.
* Both pass unmodified.
- related to
-
WT-18411 test_key_provider_disagg02 cannot detect whether the key rotation crash points fire
-
- Closed
-