DEV Community: Nayara Martins

A versão de API que vence sem avisar

Nayara Martins — Sun, 30 Aug 2026 06:31:10 +0000

Um script meu que publicava conteúdo via API do LinkedIn parou de funcionar do nada. Nenhuma linha mudou. O erro voltou assim:

{"status":426,"code":"NONEXISTENT_VERSION","message":"Requested version 20250601 is not active"}

Não tinha bug de código nenhum. A versão da API que eu tinha fixado no script simplesmente saiu da janela de suporte.

Como uma API versionada por data quebra sozinha

A API REST do LinkedIn exige um cabeçalho LinkedIn-Version no formato ano-mês, tipo 202506. Isso não é um número de versão semântica que você escolhe uma vez e esquece. É uma janela de tempo. Passado um certo período, aquela versão sai de circulação e a API recusa a chamada, mesmo que o resto do payload esteja perfeito.

O código nunca mudou entre o dia em que funcionava e o dia em que parou. O relógio do calendário é que mudou.

Por que isso engana quem debuga

O reflexo natural ao ver um erro de API é revisar o código: campo errado, token expirado, permissão faltando. Nenhuma dessas hipóteses batia. O token era válido, os escopos estavam certos, o payload era idêntico ao de uma chamada que tinha funcionado antes.

A mensagem de erro ajudou bastante aqui, porque nomeou exatamente o campo problemático (Requested version 20250601) e o motivo (is not active). Sem prestar atenção nela e ir direto pro código, essa causa levaria muito mais tempo pra aparecer.

A correção

Trocar o valor fixo do cabeçalho pela versão atual, no mesmo formato ano-mês. Nada mais no código precisou mudar.

O detalhe que fica de lição: esse valor não é constante de verdade, é uma data disfarçada de configuração. Documentei isso direto no comentário ao lado da constante, pra próxima vez que o mesmo erro aparecer a causa já estar escrita ali, em vez de descoberta de novo do zero.

A lição

Nem todo bug tem código culpado. Uma integração que depende de versão de API, certificado, ou qualquer coisa com data de validade pode quebrar sem que uma única linha do seu sistema tenha mudado. Antes de caçar bug no próprio código, vale checar se alguma dependência externa simplesmente venceu.

Nayara Martins, desenvolvedora de sistemas sob medida em Assis, SP. Mais em prospectia.space.

O dicionário que corrige acento errado sozinho

Nayara Martins — Sun, 30 Aug 2026 06:26:56 +0000

Um script meu corrige acentuação automática em português usando um dicionário de mais de noventa mil palavras. Ele existe justamente para consertar texto gerado por IA, que às vezes esquece acento. Só que hoje descobri que o próprio dicionário estava trocando "pele" por "Pelé" e "teve" por "tevê".

O corretor não tinha bug de lógica nenhum. O dado dentro dele é que estava errado.

Como um dicionário de correção vira fonte de erro

O dicionário foi gerado a partir de uma lista ampla de palavras em português, mapeando a forma sem acento pra forma com acento correspondente. Para a maioria das palavras isso funciona bem: uma palavra comum sem acento tem sempre a mesma forma acentuada certa, sem exceção.

O problema aparece em palavra que também é nome próprio. "Pele" sem acento é ambíguo: pode ser a palavra comum (pele, órgão do corpo) ou o apelido do jogador, que leva acento (Pelé). Na hora de montar o dicionário, alguma etapa do processo escolheu a forma acentuada como "a certa" para aquela entrada, sem checar que a forma comum, sem acento, é muito mais frequente no uso real.

Mesma história com "teve" (passado do verbo ter) virando "tevê" (forma informal de televisão).

Por que isso é mais perigoso que parecer

Um erro de dicionário desse tipo não quebra nada visivelmente. O texto sai fluente, gramaticalmente correto, sem nenhum sinal de que uma palavra foi trocada por engano. Quem lê rápido não percebe. Isso é o oposto de um erro de sintaxe, que pelo menos avisa que algo está errado.

A única forma de achar foi ler o texto gerado com atenção, palavra por palavra, depois de já ter rodado o corretor automático. O corretor não se autodenuncia.

Onde traçar a linha entre corrigir e não mexer

Nem toda ambiguidade é bug. Uma palavra genuinamente ambígua, tipo "e" (conjunção "e" vs verbo "é"), "esta" (demonstrativo vs verbo "está") ou "pais" (progenitores vs "país"), não tem solução de dicionário. Só quem lê a frase inteira sabe qual acento é o certo. Forçar uma escolha automática aí erra tanto quanto deixar sem acento.

A correção certa, então, tem duas partes diferentes:

Bug de verdade (palavra não ambígua mapeada errado, tipo pele/teve): remover a entrada errada do dicionário. Ela nunca devia ter sido adicionada daquele jeito.
Ambiguidade real: não tentar resolver automaticamente. Documentar a lista de palavras que exigem leitura humana antes de publicar qualquer texto gerado.

A lição

Uma ferramenta que existe pra corrigir erro pode, ela mesma, ser a origem do erro. Isso não é motivo pra desconfiar de toda automação, é motivo pra sempre ter uma segunda checagem que não depende da mesma lógica da primeira. Se o corretor e a checagem final usam a mesma fonte de verdade, um erro nela passa despercebido duas vezes.

Nayara Martins, desenvolvedora de sistemas sob medida em Assis, SP. Mais em prospectia.space.

O bug que corrige sozinho o arquivo, mas não o e-mail que ele gera

Nayara Martins — Sun, 30 Aug 2026 06:17:59 +0000

Um sistema meu estava mandando e-mail em português com acentuação errada. Não era acento faltando, era acento trocado: "operação" virava "operaÃ§Ã£o" em alguns lugares e simplesmente sumia em outros. O arquivo CSV de onde os dados vinham parecia correto quando eu abria ele. O bug só aparecia na saída final.

A causa não era o arquivo. Era a leitura dele.

O sintoma

O script lia um CSV com encoding="latin1" e escrevia de volta com encoding="latin1". Isso rodava há meses sem erro, sem exceção, sem log estranho. Só que o arquivo, na verdade, sempre foi UTF-8.

Por que isso nunca quebrou? Porque UTF-8 lido como Latin-1 é um round-trip estável. Cada caractere acentuado em UTF-8 ocupa dois bytes. Latin-1 é uma tabela de um byte só, mas cobre justamente a faixa 0x80-0xFF, então cada um daqueles dois bytes vira um caractere Latin-1 válido, só que errado (tipo "Ã" e "§" no lugar de "ç"). Escrever esses dois caracteres de volta como Latin-1 produz exatamente os mesmos dois bytes originais. O arquivo nunca corrompe. Ele só mente pra quem olha.

Onde o estrago aparece

O estrago só ficou visível quando esse texto mal lido saiu para um lugar que realmente decodifica como UTF-8: um prompt de LLM, um log em UTF-8, um e-mail. Aí os dois bytes viram os dois caracteres errados de verdade, visíveis, feios.

Ler raw.decode('latin1') nunca lança exceção, mesmo com dado sujo. Isso é o motivo do bug ter sobrevivido tanto tempo: não existe erro pra investigar, só resultado sutilmente errado.

O diagnóstico que separou hipótese de fato

Antes de mexer em qualquer script, decodifiquei o arquivo inteiro como UTF-8 puro, sem passar por nenhum código do sistema:

raw = open("dados.csv", "rb").read()
texto = raw.decode("utf-8")  # se isso não lançar erro, o arquivo já é UTF-8

Decodificou limpo, zero exceção, em um arquivo de mais de cem mil caracteres. Isso provou duas coisas de uma vez: o arquivo sempre foi UTF-8 correto, e o problema inteiro estava nos scripts que liam ele errado. Não havia dado real pra recuperar ou consertar, só a leitura errada pra corrigir.

A correção

Trocar encoding="latin1" por encoding="utf-8" em cada ponto que abria aquele arquivo específico. Nada mais. Nenhuma linha de dado foi reescrita.

O jeito de confirmar que a correção funcionou não foi só rodar sem erro. Foi gerar conteúdo de verdade a partir do fluxo completo, com vocabulário que nunca tinha passado por ali antes, e ler o resultado num lugar que expõe o problema visualmente, no caso, o corpo de um e-mail de teste.

A lição que fica

Round-trip estável esconde bug. Se ler errado e escrever errado sempre voltam pro mesmo byte, o sistema parece saudável em todo teste que só olha o arquivo. O bug só aparece no consumidor final, e só se alguém realmente olhar o resultado, não só o código de saída do processo.

Antes de assumir que um dado está corrompido, vale testar a hipótese mais simples primeiro: talvez o dado esteja certo, e a leitura é que está errada.

Nayara Martins, desenvolvedora de sistemas sob medida em Assis, SP. Mais em prospectia.space.