Repository navigation
DAB dynvar: cannot parse resource keys starting with digits when permissions are set #7387
Description
Problem
Resource keys starting with a digit (e.g. 00_clear_silver_and_gold) fail with cannot parse when permissions are defined on the resource.
Error message:
Error: cannot plan resources.jobs.00_clear_silver_and_gold.permissions: cannot parse "/jobs/${resources.jobs.00_clear_silver_and_gold.id}" Error: planning failed
The same key works fine without permissions. Renaming the key to not start with a digit (e.g. clear_silver_and_gold) while keeping name: 00_clear_silver_and_gold resolves the issue.
Reproduction
CLI version: 1.7.0
resources:
jobs:
00_clear_silver_and_gold:
name: 00_clear_silver_and_gold
permissions:
- group_name: engineer-group
level: CAN_MANAGE
- group_name: admin-group
level: CAN_MANAGE
tasks:
- task_key: example_task
notebook_task:
notebook_path: ${workspace.file_path}/src/exampleRunning databricks bundle deploy or databricks bundle plan produces:
Error: cannot plan resources.jobs.00_clear_silver_and_gold.permissions: cannot parse "/jobs/${resources.jobs.00_clear_silver_and_gold.id}"
Expected behavior
Resource keys starting with digits should be supported, consistent with how Terraform and the Databricks API handle job names.
Activity
devteamaegis commentedon Nov 10, 2026
I reproduced this on
main(688c228) with the local acceptance harness: a job keyed00_clearwith apermissionsblock failsbundle planwith the samecannot parse "/jobs/${resources.jobs.00_clear.id}"error.Cause: the direct engine links the permissions node to its job through an internal
${resources.jobs.<key>.id}reference. The reference grammar (dynvar.BaseVarDefinlibs/dyn/dynvar/ref.go, mirrored by_base_var_defin the Python package) requires each path segment to start with a letter, optionally after underscores. Leading digits are rejected on purpose: see theleading-digit-*cases inlibs/dyn/dynvar/testdata/reference_vectors.json. A key like this deploys until something has to reference it, such as permissions, grants or a user-written${resources.jobs.00_clear.id}.I see two ways to fix it:
${1}stays a literal. This would change Go, Python and the shared vectors together, the same way dynvar: fix references to resource keys with trailing underscores #6965 does for trailing underscores.bundle validatereject resource keys that can't be referenced, with a clear error.Since this changes a rule the tests check on purpose, which approach would you accept? I can send a PR for either one.
This was investigated and written with an AI coding agent (Claude) working on my behalf.