Possible error with Cache-Control caching

[ant1m4tt3r]

I was wondering if this line could cause issues by caching a possibly failed execution in the try/catch block below.

If I'm not mistaken, by setting the Cache-Control header, Vercel will cache the response of the request no mater its status, being 200 or 500. So in case the execution flow falls into the catch block, a response with an error may be cached by the CDN, causing further requests to hit that caching mechanism and receiving an error response.

Is this a farfetched thought or it may be the cause of some issues?

BrasilAPI/pages/api/cep/v2/[cep].js

Line 18 in 324fcfd

response.setHeader('Cache-Control', CACHE_CONTROL_HEADER_VALUE);

[lucianopf]

Vou responder em pr-br dado que é o padrão adotado pelo projeto e não temos objetivo de fomentar a criação de issues e PRs em outra língua ^^ (o código e commits ainda gosto de manter em ingles)

Vc tem total razão! Estamos fazendo cache de erros 😢
Se não me engano no passado a Vercel lidava com erros da classe 5xx mas parece que isso não está mais documentado e pra reforçar essa ideia temos alguns erros 404 que tbm estão ficando em cache e atrapalhando bastante a recuperação do serviço numa segunda tentativa. =/

[guilherme-aguilar]

Quando solicito uma req usando ?test deveria forcar uma nova conexao, sem uso de cache, ou nao?

// 20240308095409
// https://brasilapi.com.br/api/cep/v2/38411336?test

{
"name": "CepPromiseError",
"message": "Todos os serviços de CEP retornaram erro.",
"type": "service_error",
"errors": [
{
"name": "ServiceError",
"message": "A autenticacao de null falhou!",
"service": "correios"
},
{
"name": "ServiceError",
"message": "Erro ao se conectar com o serviço ViaCEP.",
"service": "viacep"
},
{
"name": "ServiceError",
"message": "Erro ao se conectar com o serviço WideNet.",
"service": "widenet"
},
{
"name": "ServiceError",
"message": "Erro ao se conectar com o serviço dos Correios Alt.",
"service": "correios-alt"
}
]
}

Anteriormente, estava tendo o mesmo erro devido ao cache da aplicação usei o ?test e resolveu temporariamente, agora quando voltei a usar pelo método tradicional ele apresenta novos erros.

// 20240308091121
// https://brasilapi.com.br/api/cep/v2/35530-000?test

{
"message": "invalid json response body at https://nominatim.openstreetmap.org/search?format=json&addressdetails=1&country=Brasil&state=MG&city=Cl%C3%A1udio reason: Unexpected token < in JSON at position 0",
"type": "invalid-json"
}

[guilherme-aguilar]

Notei tbm que tanto na API v1 e V2 de cep, quando faço a requisição com ou sem o "-", ele me retorna situações diferentes, algo que anteriormente também não acontecia.

Sem "-":
{
"cep": "35530000",
"state": "MG",
"city": "Cláudio",
"neighborhood": "",
"street": "",
"service": "correios-alt"
}

Com "-";

{
"message": "Todos os serviços de CEP retornaram erro.",
"type": "service_error",
"name": "CepPromiseError",
"errors": [
{
"name": "ServiceError",
"message": "A autenticacao de null falhou!",
"service": "correios"
},
{
"name": "ServiceError",
"message": "Erro ao se conectar com o serviço ViaCEP.",
"service": "viacep"
},
{
"name": "ServiceError",
"message": "Erro ao se conectar com o serviço WideNet.",
"service": "widenet"
},
{
"name": "ServiceError",
"message": "Erro ao se conectar com o serviço dos Correios Alt.",
"service": "correios-alt"
}
]
}

[carlossantosdev]

É, a API de CEP está bem ruim de usar.

Também estou tendo problemas similares.
Vários CEP's que eu testo retornam erro, tanto na API v1 quanto na API v2.

Só para compartilhar informação também, veja o caso do CEP 18103-055.

[ant1m4tt3r]

desculpa a demora para responder (e de volta ao pt-BR como foi sugerido). o que acha então @lucianopf de mantermos a cache apenas para os status 200, 400 e 404, removendo ela do status 500? posso fazer um PR para isso logo logo.