| |
|
|
|
|
|
|
|
|
|
| |
cep.is/go v0.2.0 exposes the municipality as Error.Faixa, which is what
internal/lookup existed to work around: v0.1.0 discarded the 404 body, so
the bot re-issued the request just to read the block back.
The extra GET on the 404 path is gone, and with it the second timeout,
the body size cap and the "is it still a 404?" check that guarded it.
The replies are byte for byte what they were -- the formatting tests did
not change a single assertion, only the type they build.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Answering only "não encontrei" wastes the trip. A CEP that fails is
almost never a random number: it is someone who knows the city and
guessed the rest, most often at the "-000" that 957 municipalities never
received. The API now names that municipality on the 404, so the reply
names it too.
It stays an answer to a failure. No 📮, no address block, and no CEP
suggested from inside the range — the range is sparse (Areal's 118 CEPs
span nearly five thousand numbers), so the reply gives the count and says
so instead of letting the two ends read as a list of valid CEPs.
cep.is/go v0.1.0 discards the 404 body, so internal/lookup reads it with
one extra GET, on that path alone and never inside a retry. Everything
that can go wrong there — a slow answer, broken JSON, a faixa naming no
municipality — falls back to the reply the bot has always given. The
wrapper goes away the day the library exposes the field.
|