Accept lowercase country codes in JSON Schema - #1302
Conversation
…owercase country codes when its user input
| "sx", "sy", "sz", "tc", "td", "tf", "tg", "th", "tj", "tk", | ||
| "tl", "tm", "tn", "to", "tr", "tt", "tv", "tw", "tz", "ua", | ||
| "ug", "um", "us", "uy", "uz", "va", "vc", "ve", "vg", "vi", | ||
| "vn", "vu", "wf", "ws", "xk", "ye", "yt", "za", "zm", "zw" |
There was a problem hiding this comment.
I get the heebie jeebies from this enum and am wondering why we're doing all this work in the specification.
The bug report is caused by the issue that our API forwards the path parameter without making it uppercase.
The minimal fix for this would be a strtoupper() in the API and we're done, or am I overlooking something?
It's nice to make the regex an enum, but I think we should leave that as the only change in this PR.
There was a problem hiding this comment.
That's a good question. The ticket title says the issue is [api-specification] lowercase country code accepted which insinuates the bug is in the spec (since we also use it to validate the request body).
Now that I read the ticket again getting an empty response as the ticket mentions menas it does infact pass validation and so this is not the bug.
There was a problem hiding this comment.
I think that even if this doesn't fix an actual bug in the flow we might want to keep this for semantic purposes.
The Spec does accepts lowercase country codes so having it reflected in the Spec is arguably logical
There was a problem hiding this comment.
What changed
CountryCodeUserInputfor cases country codes are passed to us by a userCountryCodemade into ENUM for better use of JSON Schema conventionspath-country_codeto useCountryCodeUserInputNOTE: The reason I introduced the additional
CountryCodeUserInputis because when we return a country code it will always be uppercase so changing that schema would be misleading.Ticket