Add scaling_schedule round-trip coverage to service suite#178
Open
sdairs wants to merge 3 commits into
Open
Conversation
sdairs
had a problem deploying
to
cloud-integration
GitHub Actions
Failure
sdairs
had a problem deploying
to
cloud-integration
GitHub Actions
Failure
sdairs
had a problem deploying
to
cloud-integration
GitHub Actions
Failure
sdairs
had a problem deploying
to
cloud-integration
GitHub Actions
Failure
sdairs
force-pushed
the
issue-169-scaling-schedule-roundtrip
branch
from
da3e20f to
4a614f9
Compare
5 tasks
Adds a Scaling Schedule phase to integration_test.rs covering the Beta
scaling_schedule_{get,upsert,replace} endpoints. The phase captures
pre-state, upserts an inert window, GETs to verify the round-trip,
PATCH-replaces with a different inert window, and GETs again. The
schedule entries use replica counts and memory identical to the current
service state (1 replica, 8 GB) so they're guaranteed no-ops even if
the window happens to be active during the test run.
Pre-state restore is wired through CleanupRegistry as a cleanup step,
not a test-body step, so a mid-phase failure still rolls back the
synthetic schedule. The restore tolerates 404 in case the in-test
delete already removed the service.
Closes #169
Fresh services have no autoscaling schedule configured, so `scaling_schedule_get` returns 404 rather than an empty schedule. The pre-state step was bubbling that 404 via `?`, failing the run under CI's fail-fast NonBlocking mode. Catch the 404 inside the closure and substitute `ScalingSchedule::default()` so the round-trip still exercises upsert/replace. Skip restore registration when the captured pre-state is empty — the API rejects upserts with `entries: []`, and there is nothing meaningful to restore (the service-delete teardown handles synthetic entries anyway).
The scalingSchedule endpoint dropped its PATCH operation; only GET, POST, and DELETE remain. The library-side swap (replace_replace → schedule_delete, plus the dropped ScalingSchedulePatchRequest) now lives in the issue-168-postgres-prometheus-and-pg-config base branch (PR #186); this commit just reworks the integration round-trip to delete + assert 404. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
sdairs
force-pushed
the
issue-169-scaling-schedule-roundtrip
branch
from
4a614f9 to
038dedf
Compare
sdairs
requested a deployment
to
cloud-integration
GitHub Actions
In progress
sdairs
changed the base branch from
md/add-clickpipes-support
to
issue-168-postgres-prometheus-and-pg-config
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
1 participant
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.
Summary
Scaling Schedulephase tointegration_test.rscoveringscaling_schedule_get,scaling_schedule_upsert, andscaling_schedule_replace(parent Close live API integration test coverage gap #151).CleanupRegistryso it runs in cleanup, not in the test body — a mid-phase failure still rolls back the synthetic schedule.Why the schedules are inert
The synthetic entries use
minReplicas=maxReplicas=1andmin/maxReplicaMemoryGb=8, identical to the current service state (the previous "scale in to 1 replica" step). Even if the window happens to be active when the test runs, the entry produces no scaling action — it's effectively a no-op. As a second line of defence, each window is one hour wide (1-2 UTC for upsert, 2-3 UTC for replace) and applies on Sunday only.Test plan
cargo build -p clickhouse-cloud-apicargo clippy -p clickhouse-cloud-api --tests(no new warnings introduced by these changes)cargo test -p clickhouse-cloud-api— 86+6+1 tests pass, ignored live tests still skippedCloses #169