- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
@animeshjain What's happening is that two different components are checking your config, and they are at different versions.
databricks bundle schema is generated from the CLI binary itself, and your CLI is latest enough enough to know about lifecycle. That's why the schema shows the field. But the error is not coming from the CLI.
Look at the traceback path: site-packages/databricks/bundles/build.py and core/_transform.py. That is the databricks-bundles Python package, which runs because your bundle has Python support enabled. With Python support on, every resource in the bundle, including ones defined in plain YAML like your volume, gets loaded into typed Python dataclasses so that Python code can see and mutate them. Those dataclasses are strict, and the transform step raises on any field the class does not declare. Your installed version of that package has a Volume class with no lifecycle field, so it rejects the config that your CLI already accepted.
Have you tried updating the Python package? You can check what you're on with
pip show databricks-bundles
If it reports anything below 0.268.0, that's your answer. Upgrade it:
pip install --upgrade databricks-bundles
or, more likely in your case, bump the pin in whatever requirements or pyproject file builds your bundle's Python environment. The
pythonEnv-.../site-packages path in your traceback shows the environment is built fresh from declared dependencies, so the old version is coming from a pin somewhere rather than from a stale machine. The package is on a 1.x version line now, so anything current is well past the fix. Nothing in your resource definition needs to change; after the upgrade, rerun validate and the volume should load cleanly, and prevent_destroy works as expected with the direct engine.