rename CreditOverage to CreditPostpaidLimit - #34
Merged
Merged
Conversation
"Overage" already means something else in the platform: a soft limit of free
units followed by a rate, on an entitlement. This field is consumption past a
zero credit balance, where there is no free allowance because the allowance was
the grant. The API side renamed to postpaid for the arrangement and overdraft
for the negative balance, so the field is the postpaid grant's overdraft limit.
The wire name gains omitempty. Absent has to be a legal payload: a client
generated from a spec predating this field decodes strictly and treats every
property it knows as required, so an empty map serialised as
"credit_postpaid_limit":{} is an unknown property to it, and a required field
missing from a payload fails validation outright. Omitting the key when the map
is empty keeps the payload legal either way, and no postpaid grant is the common
case. A new test asserts it, and fails without the tag.
Nothing needs the old spelling accepted on decode. Go ignores unknown fields, so
a payload still carrying credit_overage leaves the map empty and the company
hard-stops at zero, which is the pre-feature behavior. The feature is unreleased,
so there is no arrangement in the field to preserve.
bpapillon
marked this pull request as ready for review
September 9, 2026 21:23
schematic-bot
approved these changes
Sep 9, 2026
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
2 participants
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.
Unblocks the vocabulary rename on schematic-api#7862, which cannot finish while this field carries the old name.
"Overage" already means something else in the platform: a soft limit of free units followed by a rate, on an entitlement (
EntitlementPriceBehaviorOverage). This field is consumption past a zero credit balance, where there is no free allowance because the allowance was the grant. Two mechanisms, one word, and it misled a reviewer. The API side settled on postpaid for the arrangement and overdraft for the negative balance, so this field is the postpaid grant's overdraft limit.The three-state map is unchanged — absent means off, null means unbounded, a value means bounded. Only the names move.
The wire name gains
omitempty, and that is the part worth reviewing. Absent has to be a legal payload. A client generated from a spec predating this field decodes strictly and marks every property it knows as required, so two things can go wrong: an empty map serialised as"credit_postpaid_limit":{}is an unknown property to it, and a required field missing from a payload fails validation outright. Omitting the key when the map is empty keeps the payload legal for both, and no postpaid grant is the common case — so this is the shape most payloads take.TestCreditPostpaidLimitOmittedWhenEmptyasserts it and fails without the tag.No decode alias for the old spelling. Go ignores unknown fields, so a payload still carrying
credit_overageleaves the map empty and the company hard-stops at zero, which is the pre-feature behavior — fail-closed, no error. The feature is unreleased, so there is no live arrangement to preserve.Needs a release tag past v0.1.22 before schematic-api can bump its pin. Note
mainalready carries #32 unreleased, so that tag will include it.