iiinova — where your digital self keeps evolving

Antes, para a consulta de CNPJ, eram 3 tentativas imediatas, timeout de 3s em cada, totalizando até 9s presa por requisição. Baixei para 2 tentativas e incluí um intervalo de 100 a 300ms, com um novo teto de 2s, e o novo total pouco mais de 4s pro requisição. codeberg.org/cuducos/minh...

Mudanças? Primeiro, um “keepalive” no TCP mais apertado nas conexões com o Postgres, de 15s para 5s. Uma conexão derrubada em silêncio pela rede agora é detectada em menos de 1 min, em vez de ~2,5 min. codeberg.org/cuducos/minh... Também mudei as tentativas automáticas em caso de falha:

120

Mas o sinal de alerta estava lá: janelas em que uma consulta de 13ms passa a levar segundos. O caminho até o banco degradava até virar colapso: cerca de 3 mil goroutines presas, cada uma segurando uma requisição por 9s. A conta batia: 250 requisições vezes 9s, mais de 2 mil requisições em voo!

Dei com os burros n'água em duas investigações: 1. a migração para Go 1.27 mês passado não era, pois achei métricas parecidas antes dela, ou seja, mini episódios desses aconteciam com Go 1.26 também 2. pico de tráfego também não batia, os dias de pane tinham menos requisições que dias tranquilos

Isso vinha acontecendo já faz uns dias sem que eu notasse… e hoje foi, o pior deles. E a memória do servidor web? Plana, certa de 130MB dos 512MB disponíveis, super estável. Ou seja, também não era vazamento de memória. O mesmo dava para afirmar sobre goroutines.

O sintoma era curioso: (quase) toda consulta estourava o timeout de 3s (isso, com 3 tentativas automáticas que o backend faz, quer dizer uns 9s por requisição), enquanto o servidor do PostgreSQL ficava lá, ocioso, com mais de 95% de CPU livre. Ou seja: as queries nem chegavam ao banco!

Minha Receita @minhareceita.org · 01/10/2026

Obrigada, mais uma vez, Victor, pelo toque! Ultimamente a API viveu uma pane feia: mais de 90% das consultas de CNPJ falhando com 503. Reiniciar resolveu na hora, mas fiquei com a pulga atrás da orelha — e passei mais um tempo revirando gráficos e logs 🕵️

210

Aparentemente nada errado nos logs, ou picos de acesso, consume de memória ou CPU. Reiniciei as instâncias dos dois servidores da APi web e parece que voltou ao normal (gráfico dos últimos 30min).

Gráfico de erro por requisição por “endpoint” — No início tem uns 10min estáveis na faixa de 10mil / minuto para erros 503 na busca de CNPJ. Depois um declínio gradual que tende a zero nos próximos 5 min. E lá fica.

010

Minha Receita @minhareceita.org · 01/10/2026

Opa, não sabia que estava assim. Dando uma olhada já! Obrigada por reportar.

211

Minha Receita @minhareceita.org · 18/09/2026

Aquele aviso que (finalmente, apesar do aparente geoblocking por parte da Receita Federal), a API (incluindo grafos) está atualizada com os dados de setembro de 2026 : )

011

A @afasia.bsky.social já está me passando os dados e acho que por esse mês deve resolver. VPN pode ser uma solução de médio prazo, enquanto protocolo uma reclamação formal e aguardo resposta e coisa e tal.

140

Ou seja, não é DNS nem erro da aplicação: a conexão é derrubada no handshake do TLS, logo depois do Client Hello, e o IP é o mesmo em todo lugar. Isso reforça muito a hipótese de filtro por IP/rota na infra do servidor da Receita.

011

Já no check-host.net, o ping brasileiro recebe resposta em 96 ms. Os outros, em 19 países difernetes, recebem "Connection reset by peer" — todos falando com o mesmo IP (161.148.168.43).

check-host.net

111