Um script meu que publicava conteúdo via API do LinkedIn parou de funcionar do nada.
Nenhuma linha mudou.
O erro voltou assim: 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 no formato ano-mês, tipo .
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 () e o motivo ().
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.