Movimentação de card por robô ficou à prova de sobrescrita silenciosa
Quem integra um robô ou automação ao Pipeline recebia, junto com a recusa de uma movimentação inválida, o número da versão atual do card — e a documentação sugeria repetir a chamada com ele. Seguir essa sugestão desfazia, sem aviso, o que um atendente tivesse acabado de fazer no card. A recusa agora pede explicitamente uma nova leitura, e a documentação foi corrigida.
- CorreçãoAo recusar uma movimentação de card por falta ou erro do número de versão, o sistema deixou de devolver a versão atual e passou a pedir uma nova leitura do card. Repetir a chamada com o número que vinha na recusa podia desfazer, sem deixar rastro, o que um atendente tinha acabado de fazer.
- CorreçãoA documentação da API descrevia esse reenvio como o caminho recomendado. Foi corrigida.
- MelhoriaA recusa por conflito, quando alguém realmente mexeu no card ao mesmo tempo, continua informando a etapa e a versão atuais — ali a informação diz o que aconteceu, e não como repetir.
Disponibilidade
Esta versão está publicada no Docker Hub. Ela ainda não foi instalada nos servidores — a atualização de cada instalação é um passo separado.
O que mudou
Esta versão interessa a quem conecta um robô, uma automação ou um sistema próprio ao Pipeline. Para quem usa o painel, nada muda.
Quando um robô move um card de etapa, ele precisa declarar sobre qual versão do card está decidindo. É isso que impede que a decisão dele, tomada segundos antes, passe por cima de um atendente que arrastou o mesmo card nesse intervalo.
O problema estava no que acontecia quando essa declaração vinha ausente ou mal formada. A recusa devolvia, junto, o número da versão atual — e tanto a documentação quanto o formato da resposta convidavam a simplesmente repetir a chamada usando esse número.
O convite era ruim. Aquele número não veio de uma leitura em que o robô decidiu alguma coisa: veio da mensagem de erro. Repetir com ele faz a segunda tentativa ser aceita sempre, inclusive quando o card mudou de dono, de etapa ou foi fechado nesse meio-tempo. O resultado é pior do que a recusa original, porque agora a chamada responde com sucesso e nada indica que a decisão foi tomada sobre uma situação que já não existia.
Agora a recusa não traz mais a versão e diz, no próprio corpo da resposta, que uma nova leitura é necessária antes de tentar de novo.
O que continua igual
A recusa por conflito — quando o robô declarou uma versão válida, mas outra pessoa mexeu no card antes dele — continua informando a etapa e a versão atuais. Ali a informação tem outra finalidade: ela descreve a disputa que acabou de acontecer, para o robô entender o que mudou e decidir de novo com base no cenário novo.
A diferença entre os dois casos passou a ser explícita, porque ela importa: uma recusa significa que a integração precisa de ajuste, a outra significa que o sistema funcionou e protegeu o trabalho de alguém.
Documentação
O manual de API foi corrigido e ganhou um guia dedicado para quem coloca um agente externo para operar o Pipeline, cobrindo permissões, descoberta de capacidades, o ciclo correto de leitura e reavaliação, e como testar a disputa com um atendente de verdade.