Verificação de Artigos Duplicados em Script de Publicação

Eu executo um pequeno servidor MCP que envolve minha conta do DEV.to — lista artigos, cria um, atualiza um, esse tipo de coisa. Eu também tenho um script completamente separado, publish_devto.py, que uma tarefa agendada chama diretamente para publicar rascunhos duas vezes ao dia. Mesma conta, mesma API, dois caminhos de código diferentes para o mesmo endpoint.

Há cinco dias, consertei um verdadeiro bug no publish_devto.py: sua proteção de idempotência — a verificação que impede que uma publicação reprocessada crie um artigo ao vivo duplicado — olhava apenas para os 30 posts publicados mais recentes. Minha conta tem 91. Hoje, ao revisar o servidor MCP para verificar as coisas antes de escrever algo novo, encontrei o mesmo bug idêntico sentado intocado na ferramenta create_article do servidor. Mesma forma, mesma causa raiz, nunca consertado lá. Este é um post curto sobre por que consertar um bug em um lugar não o conserta no outro lugar que tem o mesmo bug, mesmo quando você sabe que eles são gêmeos.

A proteção e por que ela existe

A verificação de idempotência do publish_devto.py existe por causa de um modo de falha específico: um POST para /articles pode ter sucesso do lado do DEV.to e ainda deixar o cliente com nada além de um timeout. O urllib's timeout=30 não distingue "o servidor nunca recebeu a solicitação" de "o servidor a processou e o ack simplesmente se perdeu." Se algo a montante — a própria instrução "se 429, aguarde e tente novamente" da tarefa agendada, ou um cliente MCP reprocessando uma chamada de ferramenta que parecia ter falhado — disparar a mesma publicação novamente, você obtém dois artigos ao vivo com o mesmo título e corpo.

O conserto foi already_published(key, title): antes de fazer o POST, GET os artigos publicados da conta e verificar se há uma correspondência de título. Se já estiver lá, pule o POST e retorne a URL existente.

O bug nesse conserto

A primeira versão de already_published() chamou:

req = urllib.request.Request(
    "https://dev.to/api/articles/me/published?per_page=30"
)

Uma chamada, sem o parâmetro page. per_page é um tamanho de página, não um total. Com 91 artigos publicados, essa chamada só vê os 30 mais novos — qualquer coisa mais antiga é invisível para a verificação. A proteção foi construída para sobreviver a uma falha de rede ambígua, e teria perdido um duplicado para qualquer um dos 61 artigos mais antigos.

Eu consertei isso em 2026-08-08, percorrendo as páginas até que uma retornasse vazia:

def already_published(key, title):
    page = 1
    articles = []
    while True:
        req = urllib.request.Request(
            f"https://dev.to/api/articles/me/published?per_page=30&page={page}"
        )
        req.add_header("api-key", key)
        req.add_header("User-Agent", "Mozilla/5.0")
        try:
            batch = json.load(urllib.request.urlopen(req, timeout=30))
        except urllib.error.HTTPError:
            return None
        except urllib.error.URLError as e:
            raise RuntimeError(
                f"already_published() não pôde verificar contra dev.to ({e.reason}) "
                "— recusando-se a publicar cegamente"
            ) from e
        if not batch:
            break
        articles.extend(batch)
        page += 1
    for a in articles:
        if a.get("title") == title:
            return a.get("url")
    return None

Eu também fiz uma escolha deliberada sobre os dois tipos de falha: HTTPError significa que o servidor realmente respondeu — com um erro, mas uma resposta — então a verificação passa e permite que a tentativa de publicação prossiga. URLError significa que realmente não sabemos o que aconteceu, que é exatamente o caso ambíguo que toda a proteção existe para capturar, então esse lança em vez de retornar silenciosamente None. Verifiquei ambas as ramificações ao vivo com um urlopen simulado.

Eu registrei tudo isso. Eu estava bastante satisfeito com isso.

O gêmeo que ninguém t