APPZ-3053: fix the casing of snapSearchRetentionDays in the API spec - #73
Open
sergiimeleshko wants to merge 1 commit into
Open
APPZ-3053: fix the casing of snapSearchRetentionDays in the API spec#73sergiimeleshko wants to merge 1 commit into
sergiimeleshko wants to merge 1 commit into
Conversation
The warm tier retention field was documented as `snapsearchRetentionDays` (lowercase s in "search"), but the backend field is `snapSearchRetentionDays` - see TimeBasedAccountUpdateRequest.java in platform/accounts/model. A customer copying the field name from the docs sends a key the backend does not recognise. The request still returns 200 and the warm tier is simply not changed, so it reads as "the API does not support warm tier" - which is what the feature request reports. Terraform is unaffected: logzio_terraform_client hardcodes `json:"snapSearchRetentionDays"`, so `snap_search_retention_days` on logzio_subaccount has always worked. Only the raw API path was affected. Renames all four occurrences: the properties on TimeBasedAccountUpdateRequest, DetailedTimeBasedAccount and TimeBasedAccount, plus a standalone definition of the same name that is not referenced by anything. Only the five pages that embed the affected schemas are regenerated. A full `gen-api-docs` run rewrites the base64 api blob in all 198 pages with no content change, so the rest are left untouched.
✅ Deploy Preview for famous-rabanadas-f56237 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
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.
What
The warm tier retention field is documented as
snapsearchRetentionDays(lowercasesin"search"). The backend field is
snapSearchRetentionDays— seesnapSearchRetentionDaysonTimeBasedAccountUpdateRequest.javainplatform/accounts/model, andTimeBasedAccountsService.validateSnapSearchRetentionDays.Why it matters
A customer copying the field name straight from api-docs sends a key the backend does not
recognise. The request still returns
200and the warm tier is simply not changed — so from theoutside it looks like the API does not support warm tier at all.
That is what
APPZ-3053reports ("ability to adjust warm Tier via API and terraform"). Thecapability already exists; the documented field name is what is wrong.
Terraform was never affected.
logzio_terraform_clienthardcodesjson:"snapSearchRetentionDays", sosnap_search_retention_daysonlogzio_subaccounthas alwaysworked. Only the raw API path was broken.
Changes
Four occurrences renamed in
examples/logzio-public-api.yml:TimeBasedAccountUpdateRequest.snapsearchRetentionDaysDetailedTimeBasedAccount.snapsearchRetentionDaysTimeBasedAccount.snapsearchRetentionDayssnapsearchRetentionDaysdefinitionOccurrence 4 is a standalone definition under
definitions:that nothing$refs — unlike itssiblings
AccessibleandDocSizeSetting. It is renamed for consistency, but it is dead and couldreasonably be deleted instead. Happy to drop it if a reviewer prefers.
Affected doc pages
The three properties resolve into five pages, all regenerated:
update-time-based-accountgetget-allget-detailed-time-based-accountget-all-detailed-time-based-accountWhy the diff is small
Only the five pages that embed the affected schemas were deleted and regenerated. A full
yarn gen-api-docs logzrewrites the base64api:blob in all 198 pages with no content change, sothe rest are left untouched.
docs/logz/sidebar.jsis unchanged.Heads-up: do not run
yarn clean-api-docs logz— it deletes the 8 unified-alerts pages plustheir tag page, which are not generated from this spec.
Verification
snapSearchRetentionDays.api:blob of every generated page: 0 still contain the misspelling, and the5 expected pages contain the corrected name.
snapsearchRetentionDaysacross the repo returns nothing.docs/logz/sidebar.jsuntouched; all 9 unified-alerts files intact.