Skip to content

Track zstd-compressed resource state sizes in deploy telemetry (direct engine)#5604

Closed
shreyas-goenka wants to merge 1 commit into
databricks:mainfrom
shreyas-goenka:shreyas-goenka/telemetry-compressed-resource-sizes
Closed

Track zstd-compressed resource state sizes in deploy telemetry (direct engine)#5604
shreyas-goenka wants to merge 1 commit into
databricks:mainfrom
shreyas-goenka:shreyas-goenka/telemetry-compressed-resource-sizes

Conversation

@shreyas-goenka

@shreyas-goenka shreyas-goenka commented Jun 15, 2026

Copy link
Copy Markdown
Contributor

What

Bundle deploy telemetry already reports per-resource-type raw state-size statistics (state_size_{max,mean,median}_bytes in ResourceMetadata). The same per-resource state is stored zstd-compressed downstream, so this adds the compressed-size counterparts to gauge how much resource state shrinks under compression, not just the raw sizes:

  • state_compressed_size_max_bytes
  • state_compressed_size_mean_bytes
  • state_compressed_size_median_bytes

…t engine)

Deploy telemetry already reports per-resource-type raw state-size statistics
(state_size_{max,mean,median}_bytes). The deployment metadata service stores
that same per-resource state zstd-compressed, so this adds the compressed-size
counterparts to gauge how much resource state shrinks under compression rather
than just the raw sizes:

  - state_compressed_size_max_bytes
  - state_compressed_size_mean_bytes
  - state_compressed_size_median_bytes

The compressed length is computed once per resource at state-export time
(alongside the existing raw length), using github.com/klauspost/compress/zstd.
Only the direct engine is measured, matching the existing raw-size behavior.

The acceptance golden masks the compressed values (COMPRESSED_SIZE) because
they depend on the klauspost/compress version, like state_file_size_bytes is
dropped for embedding the CLI version; the dstate unit test covers real
compression behavior.

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: 5604
  • Commit SHA: bcf2d6e13bbb1e2634c9f7c8e97d83992affa841

Checks will be approved automatically on success.

@shreyas-goenka

Copy link
Copy Markdown
Contributor Author

Superseded by #5608, which has the branch on databricks/cli directly so CI (which needs OIDC/secrets, unavailable to fork PRs) can run. Same change, now using stdlib compress/flate instead of a zstd dependency.

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