Resumo

  • Em draft-ietf-cdni-ci-triggers-rfc8007bis-20, o CDN downstream precisa responder ao pedido de cancelamento, mas implementar o cancelamento real é opcional; uma tarefa pendente pode começar e uma tarefa ativa pode concluir antes que a interrupção produza efeito.
  • cancelling, cancelled, processed, complete e a exclusão do recurso são recibos distintos. Excluir pode remover a consulta de estado sem impedir a conclusão em uma ramificação distante.

Uma emergência de cache costuma produzir dois impulsos em sequência: primeiro, “remova isto”; depois, ao descobrir que o escopo estava errado, “pare”. O segundo comando parece desfazer o primeiro. Numa malha de distribuição, ele apenas entra na mesma fila temporal.

A revisão 20 do CDNI Control Interface / Triggers permite que um CDN upstream peça a outro que pré-posicione, invalide ou purgue conteúdo e metadados. Pré-posicionar antecipa a aquisição. Invalidar proíbe novo uso sem revalidação, mas não exige apagar os bytes. Purgar exige que os dados selecionados deixem de ser mantidos. Cada verbo altera uma obrigação diferente.

O cancelamento pode perder a corrida

O CDN downstream é obrigado a responder ao cancelamento, porém o rascunho torna opcional implementar a interrupção efetiva. Mesmo um pedido aceito para um gatilho pending pode chegar ao ponto de execução depois que o trabalho começou. Para um gatilho active ou processed, o downstream deveria parar, mas não garante que a atividade não termine normalmente antes disso.

O modelo de estados preserva essa diferença. cancelling diz que a interrupção foi pedida. cancelled só aparece quando o processamento parou antes da conclusão normal. Se a ação original vencer, o resultado poderá ser complete ou failed. O aceite do comando de parar não reescreve o que aconteceu alguns milissegundos depois em outro nó.

O alcance temporal da própria purga também tem limites. Dados adquiridos antes da entrada em active precisam ser atingidos; aquisições em andamento deveriam ser incluídas. Dados adquiridos depois não deveriam ser, embora o texto reconheça que isso nem sempre é realizável. A ordem não produz um corte instantâneo e universal em toda atividade de cache.

Na troca de versão, a consequência é direta. Se o novo objeto for pré-posicionado antes do fim da invalidação ou da purga anterior, ele pode chegar primeiro e ser removido depois pelo comando velho. A extensão de política de execução permite declarar dependência entre os gatilhos. Sem essa barreira, dois comandos corretos e rápidos podem gerar a ordem errada.

Processed mantém a dúvida aberta

O rascunho usa processed quando o gatilho foi criado, nenhuma atualização adicional será fornecida e a conclusão não pode ser confirmada por aquela interface. O downstream continua o processamento e, quando possível, estima o horário de término. É uma declaração de limite observável, não um sinônimo conveniente de sucesso.

Ao receber processed, o operador precisa abrir uma trilha de evidência. Numa purga, pode comparar o último estado, objetos e erros disponíveis, mudança de requisições à origem, sondas de cache e a versão efetivamente entregue. Num pré-posicionamento, pode testar a partir da região pretendida se a cópia esperada já é servida. O objetivo é impedir que “não haverá novo recibo” vire “deu certo”.

Os códigos HTTP provam etapas ainda anteriores. 201 Created confirma a criação do recurso. 202 Accepted confirma admissão sem conclusão. 204 No Content numa exclusão imediata confirma que o recurso de estado sumiu. Nenhum descreve sozinho os bytes mantidos ou entregues por cada cache.

Excluir o estado pode apagar a melhor testemunha

O rascunho trata exclusão e cancelamento como operações parecidas, com uma diferença decisiva: depois da exclusão, o recurso fica indisponível. Por isso recomenda cancelar, e não excluir, quando o estado final será necessário.

A exclusão conserva a corrida original. Um gatilho pending pode começar antes de o delete ser processado. Um active ou processed deveria parar, mas não há garantia. Assim, uma resposta de exclusão válida pode coexistir com a purga ainda avançando e com a perda do URI que permitiria acompanhá-la.

A expiração automática repete o problema mais tarde. Recursos terminais podem ser removidos e futuras consultas recebem 404. O downstream deve declarar o prazo de retenção e não deveria expirar processed enquanto execução ou redistribuição ainda puder continuar. UUIDs não reutilizados evitam que uma tarefa nova ocupe a identidade antiga; não preservam um histórico que já foi apagado.

A cascata fecha no último ramo

Um CDN de trânsito pode repassar o gatilho a outros downstreams. Ele não pode declarar complete enquanto a operação não terminar localmente e em todos os ramos atingidos. Se um ramo estiver processed, o agregado permanece processed. Um cancelamento continua cancelling até que cada downstream chegue a cancelled, complete ou failed.

Isso evita que o nó mais rápido testemunhe pelos demais. Também obriga a preservar o vínculo entre o gatilho original e os recursos intermediários, o caminho dos provedores, erros por ramo, horários de transição e observações do conteúdo depois do fechamento.

Uma topologia em diamante pode levar conteúdo ou metadados ao mesmo downstream por caminhos diferentes e com atrasos conflitantes; o documento a chama de erro de configuração. Contadores estendidos de objetos, nós e bytes ajudam a detectar volumes inesperados, mas são opcionais e acumulam o mesmo objeto processado em vários nós sem deduplicação. São sinais de anomalia, não um livro-razão de objetos únicos.

Complete é forte dentro do seu escopo

O rascunho proíbe relatar complete antes do sucesso de todas as operações listadas, inclusive nos downstreams da cascata. A garantia é substantiva e não deve ser descartada.

Mas ela responde à solicitação enviada. Uma purga que não encontra objeto conhecido pode terminar com sucesso e zero objetos afetados. O padrão selecionado pode divergir da intenção. E o CDNI separa controle, metadados, roteamento de requisições e logs. A conclusão do gatilho não prova automaticamente qual representação chegou ao usuário.

Um runbook seguro conserva cinco marcos: gatilho original, aceite pelo próximo CDN, pedido de cancelamento ou exclusão, estado terminal de cada ramo e observação independente do conteúdo. Ele não libera uma próxima ação irreversível com base apenas em cancelling, processed ou um 2xx. Antes do incidente, testa se cada parceiro realmente implementa cancelamento e estado estendido.

A revisão 20 continua sendo um Internet-Draft. O registro congelado da IANA ainda lista os tipos do RFC 8007, não os .v2 propostos, e as fontes não demonstram adoção por um CDN identificado. A contribuição presente é um limite claro: aceitar o cancelamento prova que a solicitação entrou; não prova que a purga deixou de acontecer.

Fontes