Conversation
The test expected phase "Created" for valid cluster names, but "Created" is a transient state that immediately transitions to "Pending" when daskcluster_create_components fires. On Python 3.12, faster asyncio internals cause this transition to complete before the test poll reads the status, resulting in "Pending" instead of "Created". Change the test to check != "Error" for valid names instead of expecting a specific transient phase. The test validates name validation logic, not phase lifecycle, so this accurately reflects its intent and works across all Python versions. Fixes Python 3.12 failure in: https://github.com/dask/dask-kubernetes/actions/runs/21955249462/job/63417295766 Related to dask#968
pkg_resources (from setuptools) is no longer bundled by default in Python 3.12 CI environments, causing ModuleNotFoundError at import time. Replace with importlib.metadata.entry_points which is in the stdlib since Python 3.9 (project requires >=3.10). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
7e6df02 to
08e8503
Compare
dask[complete] pulls in jupyter packages that upgrade jsonschema to 4.18+, which removed _legacy_validators. k8s-crd-resolver requires openapi-spec-validator<0.5.0 which depends on that internal module. Re-pin jsonschema==4.17.3 at the end of ci/install-deps.sh so the pin survives the dask[complete] install. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
08e8503 to
a45a401
Compare
setuptools 82 removed pkg_resources, which openapi-spec-validator<0.5.0 needs at import time. This caused prance to fail backend detection with "No validation backend available!" in the customresources test fixture. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
4499f42 to
914a360
Compare
|
Hey! Heads-up: I'm not deeply familiar with this codebase. I noticed the Python 3.12 CI failures and used an AI assistant to help diagnose and propose these fixes. The analysis and local reproduction look solid, but I'd really appreciate a careful review since I can't vouch for every nuance of the controller/test behavior. In particular: Test assertion change — switched from asserting exact phase "Created" to != "Error" for valid names, to avoid the async timing race between Created → Pending. Is this the right level of strictness? |
Summary
test_create_cluster_validates_nameassertion that raced between "Created" and "Pending" phases on Python 3.12 (relates to DaskCluster stuck in Pending state - Possible race condition? #968)import pkg_resourceswithimportlib.metadata.entry_points()in the controller for Python 3.12 compatibility (setuptools 82 removedpkg_resources)setuptools<81andjsonschema==4.17.3in CI to fixk8s-crd-resolver/prancebackend detection failure (openapi-spec-validator<0.5.0still needspkg_resourcesat import time)Details
Test fix: The test previously asserted an exact phase (
"Created"), but on Python 3.12 the async handler chain runs faster, causing a race where the poll catches"Pending"instead. Changed to assert!= "Error"for valid names, which is correct across all Python versions.Controller fix:
pkg_resourceswas removed from setuptools 82. The controller used it for plugin discovery viaiter_entry_points. Replaced withimportlib.metadata.entry_points()(stdlib since Python 3.9).CI fix:
openapi-spec-validator0.4.0 (required byk8s-crd-resolver) importspkg_resources.resource_filenameat module level. With setuptools 82, this import fails, causing prance to report "No validation backend available!". Pinningsetuptools<81restorespkg_resourcesavailability. Also re-pinsjsonschema==4.17.3afterdask[complete]installs, sinceopenapi-spec-validator<0.5.0needsjsonschema._legacy_validators(removed in 4.18+).Test plan