SEZ9 commented on PR #13002: URL: https://github.com/apache/seatunnel/pull/13002#issuecomment-6674937323
Thanks @DanielLeens. Rebased and issue 1 fixed. **Rebase.** #13000 merged on 2026-11-05, so this stack no longer carries its commits. New head `ca0fd6875`, which is `dev` + the empty-plan guard (#13001) + the two commits for this PR. Diff against `dev` is now 3 files, +598/-5. **Issue 1 — runtime-metadata-dependent tests.** You were right, and the tests were passing here by accident: no metadata is exported on my machine, so `_registered_connector_names()` returns None and the comparison falls back to names as given. The registry path was never exercised. I reproduced your scenario — a registry that exports `Jdbc` but not `MySQL-CDC` — and five tests go red: ``` FAILED ConformanceCheckTest::test_wrong_source_connector_is_reported FAILED DriftReachesTheRepairLoopTest::test_a_valid_but_wrong_config_is_sent_for_repair FAILED DriftReachesTheRepairLoopTest::test_the_repair_is_told_the_request_and_the_plan FAILED DriftMergedWithValidatorOutputTest::test_drift_alone_when_the_validator_passed FAILED DriftMergedWithValidatorOutputTest::test_every_validator_issue_survives_the_merge ``` Exactly as you described: the planned name is filtered out, the expected drift becomes an empty list, and the failure has nothing to do with the code. A `PinnedRegistryMixin` now fixes the catalog for every class that exercises drift, so the registry is a fixture rather than an input. The three registry-specific tests keep their own narrower patches, which take precedence inside their blocks, and the unavailable-registry case still asserts the fallback. Same scenario with the pinning in place: 16 passed. Kept at the test boundary, as you said — changing production discovery to suit tests would be the wrong layer. Suite from `seatunnel-cli/`: 370 passed, 3 subtests passed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
