docs(api): document registerDomain's idempotent reclaim behavior - #981
Open
AmirF194 wants to merge 1 commit into
Open
docs(api): document registerDomain's idempotent reclaim behavior#981AmirF194 wants to merge 1 commit into
AmirF194 wants to merge 1 commit into
Conversation
registerDomain has always returned 201 with the existing row when the caller re-registers a domain it already owns (tokencanopy#819 depends on this), but the operation carried no description, unlike its listDomains, deleteDomain, and verifyDomain siblings, and docs/design/api-v1-redesign.md stated the opposite: that a retry always 409s. A caller reading only the spec could not tell whether a retry was safe, and a caller reading the design doc was told it was not idempotent. Add a Description to the registerDomain operation, regenerate api/openapi.yaml and the two generated SDK bases, add one line to docs/api.md, and correct the two design-doc lines that asserted the 409 premise. Purely additive; the 201 status code itself is intentionally unchanged (frozen at v1.5.0, and the Python SDK's generated client only maps '201'). Fixes tokencanopy#824
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.
Summary
registerDomainhas always returned 201 with the existing row when a caller re-registers a domain their own account already owns (#819's plan-cap exemption depends on this). That behavior was undocumented everywhere except a code comment, and one design doc stated the opposite: that a retry always 409s. This PR documents the real behavior and corrects the false premise.Client surface checklist
make specthenmake generate-sdk)What changed
Descriptionto theregisterDomainoperation (internal/httpapi/domains.go), matching itslistDomains/deleteDomain/verifyDomainsiblings, which already had one.api/openapi.yamland both generated SDK bases from it.docs/api.md's domains section.docs/design/api-v1-redesign.md, which twice said aregister_domainretry is "a 409, never a duplicate." It reclaims the existing row with 201.Explicitly not changing
The 201 status code itself stays as is.
/v1is frozen at v1.5.0, so201 -> 200would be a breakingresponse-success-status-removedchange under the compat gate, and the Python SDK's generated client only deserializes'201'for this operation, so200would silently returnNoneto callers. This PR is documentation only.Verification
go test ./internal/httpapi/...green, including the two existing tests that already pin this behavior (TestRegisterDomainAtCapAllowsReclaimOfOwnedDomain,TestRegisterDomainAtCapStillReturnsConflictForAnotherAccountsDomain).make spec-checkandmake openapi-compat-check(against upstreammain) both clean: no drift, no breaking changes.make generate-sdk-check's normalization tests andscripts/check-sdk-operation-coverage.pyboth pass; the only generated-code diff is the new description string in the domains API docstrings.go build ./...,go vet ./internal/httpapi/..., andgofmtare clean. Did not run the full DB-backed integration/e2e suites, since nothing here touches runtime behavior.Fixes #824