feat(monitor config): add --history-start-date flag#12
Open
Conversation
Surfaces the metricMonitoring.historicalMetricCollectionScanStartDate
field via the CLI. Accepts three input forms:
--history-start-date 120d (relative: also Nm = months, Ny = years)
--history-start-date 2026-01-03 (calendar date, midnight UTC)
--history-start-date 2026-01-03T00:00:00Z (RFC3339)
Validation: must be in the past; warns when > 2 years ago since Soda
may not retain data that far back.
Refactors monitor config update to fetch the current config first and
merge user overrides into it before POSTing. POST /api/v1/datasets/{id}
with metricMonitoring.enabled=true rejects payloads that omit
scanSchedule and datasetMetricMonitorsConfiguration, so we always send
them back from the current state. Same merge applies to --schedule and
--timezone — the existing handler discarded them on every write.
Adds an explicit guard: --enable on a dataset with no existing schedule
or monitor configuration now errors with a pointer to
`sodacli dataset onboard --monitoring`, instead of failing opaquely
server-side.
Stdlib only (time, regexp, strconv).
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
Surfaces the
metricMonitoring.historicalMetricCollectionScanStartDatefield via the CLI. Accepts three input forms:Validation: must be in the past; warns when more than 2 years ago since Soda may not retain data that far back.
Refactors
monitor configupdate to fetch the current config first and merge user overrides into it before POSTing.POST /api/v1/datasets/{id}withmetricMonitoring.enabled=truerejects payloads that omitscanScheduleanddatasetMetricMonitorsConfiguration, so we always send them back from current state. Same merge pattern applies to--scheduleand--timezone— the existing handler discarded them on every write.Adds an explicit guard:
--enableon a dataset with no existing schedule or monitor configuration now errors with a pointer tosodacli dataset onboard --monitoring, instead of failing opaquely server-side.Stdlib only (
time,regexp,strconv).Test plan
sodacli monitor config <id> --history-start-date 120dwrites RFC3339 ~120 days agosodacli monitor config <id> --history-start-date 2026-03-15writes midnight UTC of that datesodacli monitor config <id> --history-start-date 3ywrites RFC3339 ~3 years ago AND emits a >2y warningsodacli monitor config <id>(read-only) shows the new "Historical from" value--history-start-date "tomorrow"errors with format hint--history-start-date 2030-01-01errors with "must be in the past"