Add postgres_snapshot_schedules bundle resource - #6449
Draft
janniklasrose wants to merge 5 commits into
Draft
Conversation
janniklasrose
force-pushed
the
janniklasrose/postgres-snapshot-schedules
branch
from
August 31, 2026 20:29
a34c52d to
f1196c2
Compare
## Changes
Add the `postgres_snapshot_schedules` bundle resource, which manages the
automatic-snapshot schedule of a Lakebase Postgres branch.
The snapshot schedule is a per-branch singleton with no create or delete API —
only `GetSnapshotSchedule` and `UpdateSnapshotSchedule`. The resource maps the
lifecycle onto that single write call:
- create/update set the branch's schedule via `UpdateSnapshotSchedule`
(update_mask `schedule`, awaiting the long-running operation);
- delete disables automatic snapshots by setting an empty cadence set, since
DoDelete also fires when the resource is removed from config, not only on
`bundle destroy`;
- `branch` composes the schedule's hierarchical name and is a provided id field
(a change recreates).
Modeled on the existing `postgres_*` resources. Direct engine only: the schedule
was added in databricks-sdk-go v0.177.0 and the pinned Terraform provider has no
equivalent resource yet, so the acceptance and bind tests are pinned to the
direct engine.
## Tests
- direct-engine unit CRUD (`bundle/direct/dresources`);
- acceptance (direct engine), four end-to-end scenarios, each reading the
schedule back with `postgres get-snapshot-schedule`:
- `basic`: create with a cadence, in-place cadence update, then remove the
resource from config, which disables the schedule (reads back
`schedule: null`);
- `update`: add the schedule to an already-deployed branch, then remove it;
- `out-of-band`: an out-of-band `update-snapshot-schedule` is detected as
drift by `bundle plan` (`update postgres_snapshot_schedules.main_schedule`)
and reconciled back by deploy;
- `orphaned`: removing the branch from config while keeping the schedule that
references it — the reference still resolves from the deployed state, so
validate passes and plan sequences a branch delete alongside a schedule
recreate (documented, not a validation error);
- the invariant and bind/unbind suites;
- resource-enumeration unit tests (bind support, run_as, permissions,
target-mode) extended for the new type.
Acceptance goldens regenerated via `-update`; the verify pass is green apart
from pre-existing load-induced terraform-engine timeout flakes, each confirmed
passing in isolation.
Co-authored-by: Isaac <no-reply@databricks.com>
janniklasrose
force-pushed
the
janniklasrose/postgres-snapshot-schedules
branch
from
September 1, 2026 08:08
4c0b285 to
686d31b
Compare
Drop the `update` subtest (create/update/remove is already covered by `basic`) and the `orphaned` subtest (deleting a branch while keeping a schedule that references it is user error — it plans but fails at apply, which we don't need to pin in a golden). Co-authored-by: Isaac <no-reply@databricks.com>
DoCreate built the schedule resource name as `config.Branch + "/snapshot-schedule"`, which doubles the separator if a user writes `branch:` with a trailing slash. Route it through snapshotScheduleName, which trims trailing slashes first, and cover it with a unit test. Co-authored-by: Isaac <no-reply@databricks.com>
Add a `bundle plan` after the removal step in the basic acceptance test; it reports "0 to add, 0 to change, 0 to delete" (project and branch unchanged), confirming the disable settled cleanly and leaves no lingering drift. Co-authored-by: Isaac <no-reply@databricks.com>
janniklasrose
commented
Sep 1, 2026
Comment on lines
-1132
to
+1167
| deleteIsNoop := strings.HasSuffix(group, "permissions") || strings.HasSuffix(group, "grants") | ||
| // postgres_snapshot_schedules has no delete endpoint: DoDelete disables the | ||
| // schedule by setting an empty cadence set, and the schedule remains readable | ||
| // (it is intrinsic to the branch), so DoRead still succeeds afterwards. | ||
| deleteIsNoop := strings.HasSuffix(group, "permissions") || strings.HasSuffix(group, "grants") || group == "postgres_snapshot_schedules" |
Contributor
Author
There was a problem hiding this comment.
maybe we can rename deleteIsNoop? It implies that DoDelete does nothing, but it does (at least to the best of its abilities, updating it to the default empty object)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Caution
Stacked on #6448 but still missing the TF bump
Changes
Add the
postgres_snapshot_schedulesbundle resource, which manages the automatic-snapshot schedule of a Lakebase Postgres branch.The snapshot schedule is a per-branch singleton with no create or delete API — only
GetSnapshotScheduleandUpdateSnapshotSchedule. The resource maps the lifecycle onto that single write call:UpdateSnapshotSchedule(update_maskschedule, awaiting the long-running operation);bundle destroy;branchcomposes the schedule's hierarchical name and is a provided id field (a change recreates).Modeled on the existing
postgres_*resources. Direct engine only: the schedule was added in databricks-sdk-go v0.177.0 and the pinned Terraform provider has no equivalent resource yet, so the acceptance and bind tests are pinned to the direct engine.Tests
bundle/direct/dresources);Acceptance goldens regenerated via
-update; the verify pass is green apart from pre-existing load-induced terraform-engine timeout flakes, each confirmed passing in isolation.