[fast-ut] [reduced-it] [SkipRecovery] Restore Delta deletion vector write coverage [databricks] - #15477
[fast-ut] [reduced-it] [SkipRecovery] Restore Delta deletion vector write coverage [databricks]#15477wjxiz1992 wants to merge 1 commit into
Conversation
Signed-off-by: Allen Xu <allxu@nvidia.com>
There was a problem hiding this comment.
Pull request overview
This PR updates Delta Lake write integration test markers to reflect that the deletion-vector (DV) write coverage gap tracked in #12027 has been fixed (via #12451), restoring normal CPU/GPU parity execution for DV-enabled cases on Databricks runtimes.
Changes:
- Remove the parameter-level
xfailreason for DV-enabled writes that referenced #12027, switching back to the standarddeletion_vector_valuesparametrization. - Keep the managed-table test’s existing Databricks
xfails for the still-open issues (#13106, #11169), while dropping the now-redundant #12027 reason.
Greptile SummaryRestores normal CPU/GPU parity coverage for five Delta deletion-vector write cases and removes a redundant parameter-level expected-failure reason from the managed-table case.
Confidence Score: 5/5The PR appears safe to merge because it only restores execution of previously expected-failing test parameters while preserving collection and parity-check behavior. The plain deletion-vector parameter list retains the same runtime-dependent values as the former helper, reduced-IT selection retains these single-parameter cases, and the managed test remains covered by its two function-level Databricks xfails. Important Files Changed
Reviews (1): Last reviewed commit: "test: restore Delta deletion vector writ..." | Re-trigger Greptile |
JaCoCo sql-plugin line coverage: not measurable locally — DBR 14.3 shim classfiles do not match the Apache shim350 nightly baseline
Contributes to #12027
Summary
tightBoundsstat in Delta Lake tables is set incorrectly #12027-specific expected-failure reason after the fix in Match logic of DV enabling in Gpu Stats Collection [databricks] #12451.tightBoundsstat in Delta Lake tables is set incorrectly #12027 reason from the managed-table case without counting it as recovered; the remaining Databricks xfails are tracked by [BUG]delta_lake_write_test::test_delta_write_round_trip_managedfails due to mismatched output on Databricks 14.3 #13106 and Delta Lake compaction writes can fallback due to WriteIntoDeltaCommand #11169.Recovered parameters
test_delta_write_round_trip_unmanaged[True]test_delta_overwrite_round_trip_unmanaged[True]test_delta_append_round_trip_unmanaged[True]test_delta_write_round_trip_cdf_write_opt[True]test_delta_write_aqe_join[True]Relinked, not recovered
test_delta_write_round_trip_managed[True]is not counted as recovered. This change only removes its redundant #12027 parameter-level reason; the test remains covered by the open Databricks xfails in #13106 and #11169.Validation
Exact source:
7e457724a96a4367cb74e79e8404d1d35122517fplus this marker-only patch.python3 -m py_compile integration_tests/src/main/python/delta_lake_write_test.pypython3 integration_tests/src/main/python/reduced_it_selection_test.py(exit 0; all three single-parameter cases retained)350db143, focused:5 passed, 2 warnings in 192.12s400db173, focused:5 passed, 5 warnings in 93.28sdelta_lake_write_test.py: 150 unique JUnit cases across 8 isolated Spark processes;106 passed, 23 skipped, 20 xfailed, 1 xpassed; 0 failures/errorsdelta_lake_write_test.py: 150 unique JUnit cases;123 passed, 2 skipped, 23 xfailed, 2 xpassed, 5 warnings in 901.01s; 0 failures/errors+107lines on the matching class subset, but JaCoCo reported 432 runtime/classfile mismatches, so no numeric delta is claimedDocumentation
Testing
(Please provide the names of the existing tests in the PR description.)
Performance