Skip to content

bundle: validate recorded state size during bundle validate - #6083

Closed
shreyas-goenka wants to merge 2 commits into
databricks:mainfrom
shreyas-goenka:shreyas-goenka/validate-state-size
Closed

bundle: validate recorded state size during bundle validate#6083
shreyas-goenka wants to merge 2 commits into
databricks:mainfrom
shreyas-goenka:shreyas-goenka/validate-state-size

Conversation

@shreyas-goenka

@shreyas-goenka shreyas-goenka commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

Changes

This is a best effort and slightly in-perfect validation to error early if we detect users will have really large state sizes. Rather than failing at runtime.

The deployment metadata service rejects a resource state over 64 KiB
(MAX_STATE_BYTES) with InvalidArgument. Hitting that mid-apply fails a deploy
after some resources have already been created, so check it up front instead.

The state checked here is what the deploy path uploads: the state prepared from
config, serialized with sensitive fields redacted. It is a pure config
transform, so it needs no workspace request and belongs in FastValidate, which
runs for both `bundle validate` and `bundle deploy`.

The check is scoped to direct-engine deployments that opted into
experimental.record_deployment_history, since no other deployment uploads this
state. FastValidate now takes the resolved engine rather than reading
bundle.engine, which reports terraform when DATABRICKS_BUNDLE_ENGINE selects it.

Co-authored-by: Isaac
"Split it up" means a different edit per resource type, so name the split that
applies: multiple jobs with fewer tasks, multiple alerts with fewer conditions,
multiple pipelines with fewer libraries.

file_path on alerts (and dashboards/genie spaces) is deliberately not suggested.
LoadDBAlertFiles inlines the file into AlertV2 during initialize, so the recorded
state is byte-identical whether the body came from file_path or from inline YAML;
recommending it would send users on a refactor that does not reduce the size.

Co-authored-by: Isaac
@github-actions

Copy link
Copy Markdown
Contributor

An authorized user can trigger integration tests manually by following the instructions below:

Trigger:
go/deco-tests-run/cli

Inputs:

  • PR number: 6083
  • Commit SHA: 1e460c9bdc38a9045e4403cbb08c1183c0449f5f

Checks will be approved automatically on success.

@shreyas-goenka
shreyas-goenka marked this pull request as ready for review July 28, 2026 14:08
@github-actions

Copy link
Copy Markdown
Contributor

Approval status: pending

/acceptance/bundle/ - needs approval

5 files changed
Suggested: @denik
Also eligible: @pietern, @andrewnester, @janniklasrose, @lennartkats-db, @anton-107

/bundle/ - needs approval

4 files changed
Suggested: @denik
Also eligible: @pietern, @andrewnester, @janniklasrose, @lennartkats-db, @anton-107

/cmd/bundle/ - needs approval

Files: cmd/bundle/utils/process.go
Suggested: @denik
Also eligible: @pietern, @andrewnester, @janniklasrose, @lennartkats-db, @anton-107

Any maintainer (@andrewnester, @anton-107, @denik, @pietern, @simonfaltum, @renaudhartert-db, @janniklasrose, @lennartkats-db) can approve all areas.
See OWNERS for ownership rules.

@shreyas-goenka

Copy link
Copy Markdown
Contributor Author

Superseded by #6087. This PR was opened from a fork, and fork PRs cannot obtain the GitHub OIDC token the JFrog auth step requires, so every task test job failed before compiling anything. #6087 has the same commits on a branch in the main repo so CI can run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant