Hi, a few Databricks-specific things to check here. "From bundle" plus imports that come and go on the same runtime usually points at how the wheel gets packaged and installed across runs rather than at your code.
On the runtime itself: DBR 17.3 is an LTS release (GA Oct 22, 2025, Spark 4.0.0), so a broad runtime-side import regression is unlikely. That makes a packaging or install-caching interaction the more probable cause, and those are fixable from the bundle side.
The most common cause of cannot import name ... / no module named ... that flips between runs with no code change is a stale wheel being installed on some runs but not others:
-
Same wheel version across rebuilds. If your wheel keeps the same version (say 0.0.1) between deploys, pip sees the requirement as already satisfied and can skip reinstalling it on compute that is warm or reused, so a newly added or renamed symbol is missing on those runs. Databricks added a setting for exactly this: put dynamic_version: true on your whl artifact and each deploy patches the wheel version suffix from the file timestamp, so new code always installs without you bumping the version in setup.py/pyproject.toml. It shipped in Databricks CLI 0.245.0 and is documented under artifacts. There is also a ready-made preset, artifacts_dynamic_version, that the default-python template enables for classic compute (see Custom presets).
artifacts:
my_wheel:
type: whl
dynamic_version: true
build: uv build --wheel
-
More than one wheel left in dist/. If your library reference is a glob like whl: ./dist/*.whl and older wheels are still sitting in dist/, the install can match an older file on some runs. Clean dist/ before each build, or point at the exact filename, so only the current wheel is present. (This class of issue shows up in this community thread.)
To confirm which run got which build, compare a passing run and a failing run: log the installed version of your package at the top of the task (importlib.metadata.version("<pkg>") or pip show <pkg>) and check it against the wheel version/timestamp your deploy produced. If passing and failing runs show different installed versions, it is the caching path above and dynamic_version will settle it.
On "is anyone else seeing this today": since it began about two days ago with no change on your side, it is worth ruling out a redeploy that reused the same version (a scheduled CI job, or a teammate's deploy) landing unevenly across warm job clusters. If the installed versions match on passing and failing runs and the wheel is clean, grab the run IDs of one passing and one failing run and open a support ticket, and check the Azure status page for your region.
(If your bundle deploys source files rather than a wheel, the same on-again/off-again behavior can instead come from sys.path/workspace-files resolution; the version-logging check above will tell you which path you are on.)
