telegram/internal/app, branch mainOfficial cep.is Telegram bot - @cepisbot
http://git.cep.is/telegram/atom?h=main2026-07-28T00:12:05ZRead the faixa from the client instead of fetching it again2026-07-28T00:12:05ZMurilo Ijancmurilo@ijanc.org2026-07-28T00:12:05Zurn:sha1:97b49ae7081b989274b313532ff17c71694097a9
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.
Name the municipality when the CEP does not exist2026-07-27T23:46:40ZMurilo Ijancmurilo@ijanc.org2026-07-27T23:46:40Zurn:sha1:83ce95cf10fd9e9d581362453c558239d37ae06e
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.
Initial import2026-07-26T18:18:21ZMurilo Ijancmurilo@ijanc.org2026-07-26T18:18:21Zurn:sha1:3ca1d2c4370e8e79aba3940d5c8fe115960b75a8