Resumo

  • As notas de lançamento da PeeringDB dão 21 de outubro como data da versão 2.84.0 e registram a correção de exclusões ligadas à verificação de estado em RIRs que não chegavam a clientes do parâmetro ?since=. O relato original mostra linhas netixlan apagadas diretamente e redes marcadas deleted sem avanço no campo updated.
  • O commit integrado no dia 20 remove a operação de exclusão em massa e testa a resposta externa da API para objetos apagados. Para corrigir o acúmulo anterior numa cópia local, o relator indica uma nova sincronização integral. Não há contagem pública de cópias que já fizeram esse trabalho.

O cadastro andou. A cópia ficou.

Uma equipe consulta a PeeringDB para descobrir se vale iniciar contato com uma rede num ponto de troca. Outra usa o espelho local, que permite consultas rápidas e integração com ferramentas internas. A primeira não vê mais a presença; a segunda continua vendo. Uma linha de diretório não confirma sessão BGP ativa, porém é capaz de pôr gente para trabalhar. O erro de sincronização coloca duas equipes diante de retratos diferentes do mesmo cadastro público.

A especificação da API oferece uma forma econômica de manter cópias: ?since= devolve objetos alterados desde um horário Unix, e objetos apagados podem ser consultados com status=deleted e um since positivo. A FAQ da PeeringDB descreve a rotina do peeringdb-py: primeira carga integral, atualizações posteriores só com alterações. É uma troca razoável. O cliente evita pedir todo o banco; o serviço garante que toda alteração relevante entre no fluxo. Uma exclusão sem registro de mudança transforma eficiência em memória seletiva.

No ticket oficial #2057, aberto em 7 de outubro, Remco van Mook comparou uma réplica atualizada por ?since= com listagens completas da API. Encontrou um caminho de limpeza periódica de redes cujo estado no RIR já não sustentava o cadastro. Antes de apagar a rede, o programa removia em massa suas linhas netixlan, as ligações entre rede e LAN do ponto de troca. Essa operação não chamava o método de exclusão que marcaria cada objeto como deleted e moveria updated. O dado sumia na origem sem emitir o evento que a réplica procurava.

Havia outro caminho para a mesma divergência. Algumas redes apareciam como deleted na PeeringDB, mas conservavam o horário anterior em updated. Os exemplos do ticket mostram exclusões relacionadas a 2026 em objetos cuja atualização continuava datada de 2022. O cliente que pede novidades posteriores à sua última consulta recebe uma resposta coerente com o relógio errado. Ele pode registrar uma sincronização concluída e guardar uma rede que o cadastro central já retirou.

O alcance que o ticket consegue medir

O relator encontrou 286 linhas netixlan apagadas em massa, ligadas a 125 redes ao longo de cerca de seis meses, e 46 redes apagadas sem mudança no campo updated. Os números delimitam a comparação feita por ele. O total de usuários da API atingidos e de decisões tomadas com dados atrasados não foi publicado. É o mecanismo, reproduzido com identificadores e horários, que torna o caso sólido.

Um comentário de 9 de outubro revelou a falha inversa: 569 linhas netixlan ativas na origem faltavam na réplica, distribuídas por 349 redes e 279 pontos de troca. O autor propôs duas hipóteses de sequência, uma transação que se tornou visível depois de a janela do cliente passar ou uma restauração sem novo horário. O comentário não identifica qual ocorreu. A solução para a exclusão em massa não resolve por associação esse desaparecimento de linhas ainda ativas.

No dia 20, a PeeringDB incorporou o commit 81ac767. Ele retira a chamada de remoção em massa das conexões e deixa a própria exclusão da rede processar as dependências. O teste novo monta uma rede com conexões e contato técnico, executa a limpeza por estado RIR e exige que rede e conexões fiquem deleted, com updated recente. Por fim, faz GET /api/netixlan?since=... e exige que a resposta traga as conexões apagadas. A mudança é pequena no código e grande no contrato: a prova é o que um cliente consegue ler.

As notas da versão 2.84.0 datam o lançamento de 21 de outubro e descrevem #2057 como conserto para quem sincroniza. A tabela de planejamento do mesmo site apontava 20 de outubro como alvo de produção. O merge ocorreu no dia 20; o lançamento publicado leva a data do dia 21. Essas datas não são medidas de quantas réplicas antigas foram reconciliadas.

Um conserto na origem não visita cada réplica

Uma linha removida sem tombstone não permanece na base para emitir amanhã o aviso esquecido. Uma rede cuja atualização ficou em 2022 também não vai aparecer numa consulta que parte de 2026. Segundo o ticket, quem já acumulou divergência precisa de uma carga completa. A PeeringDB não publicou uma contagem de espelhos refeitos, nem um quadro do atraso remanescente. Um registro verificável dessas recargas mudaria a avaliação do passivo.

A carga completa cobra o trabalho que o delta prometia poupar. Essa é a dimensão de governança do caso: a instituição que administra o cadastro controla a operação de exclusão e o contrato da API; cada usuário controla a réplica onde decisões são preparadas. Quando a origem deixa de publicar uma transição, a consequência prática pode morar fora de seus servidores por meses. Uma tarefa de sincronização bem-sucedida não basta para certificar que o conteúdo coincide.

O rascunho da API v3 torna a obrigação mais explícita ao exigir que deltas incluam exclusões e retiradas, com instantâneos diários como base e recuperação. É um projeto em consulta. O incidente da 2.84.0 oferece a prova que sua futura implementação terá de passar: uma mudança de estado público precisa de identidade, ordem e confirmação consumível. A disponibilidade de uma API mede se ela responde; a integridade do delta mede se ela contou tudo.

No fim, o fantasma nasceu de uma distinção esquecida: remover uma linha do banco e anunciar sua remoção são dois atos. O primeiro aconteceu. O segundo agora tem um teste. As cópias que passaram pela fase silenciosa ainda precisam ser chamadas de volta ao presente.