Verifica o resultado antes de anunciar a exclusão de demanda - #90
Merged
Merged
Conversation
Os dois controllers de demanda anunciavam sucesso sem olhar o retorno de #destroy: a tela redirecionava com "Demanda excluída com sucesso." e a API respondia 204, acontecesse o que acontecesse. Hoje isso está sempre certo, porque nada impede a exclusão de uma demanda — mas por coincidência, não por verificação. Um `dependent: :restrict_with_error`, um `before_destroy` que dê `throw :abort` ou uma FK nova fariam as duas interfaces afirmarem que o registro sumiu enquanto ele continua no banco. O caminho de erro que entra aqui não é alcançável agora; é essa a razão de ele existir. O contraste com Users::Destroy é o que motivou a issue: aquele serviço existe justamente porque a exclusão de usuário TEM impeditivos (conta própria, demandas vinculadas) e precisa comunicá-los. Demandas seguiam o padrão oposto sem que a diferença estivesse registrada em lugar nenhum — agora está, nos dois controllers. Não criei um Demandas::Destroy. Sem regra de negócio para compartilhar entre web e API, seria uma classe só para embrulhar uma chamada; o dia que houver impeditivo de verdade, aí a extração se paga. Os dois lados têm fallback de mensagem porque `throw :abort` devolve false sem popular errors — sem ele a tela mostraria um alerta vazio e a API, uma lista vazia. A API usa o mesmo formato de erro de #create e #update (array de strings, 422). Verificado no container: RuboCop 110 arquivos sem ofensas, zeitwerk:check limpo, RSpec 388 exemplos e 0 falhas (eram 384). Closes #83 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
github-project-automation
Bot
moved this from Backlog
to Done
in @Hirley's task_keeper_api
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fecha a #83.
Os dois controllers de demanda anunciavam sucesso sem olhar o retorno de
#destroy: a tela redirecionava com "Demanda excluída com sucesso." e a API respondia204, acontecesse o que acontecesse.Hoje isso está sempre certo, porque nada impede a exclusão de uma demanda — mas por coincidência, não por verificação. Um
dependent: :restrict_with_error, umbefore_destroycomthrow :abortou uma FK nova fariam as duas interfaces afirmarem que o registro sumiu enquanto ele continua no banco.O caminho de erro que entra aqui não é alcançável agora. É essa a razão de ele existir, e está comentado assim nos dois lugares — para que quem introduzir o primeiro impeditivo não precise descobrir isso pelo bug.
O que motivou a issue
O contraste com
Users::Destroy, que existe justamente porque a exclusão de usuário tem impeditivos (conta própria, demandas vinculadas) e precisa comunicá-los. Demandas seguiam o padrão oposto sem que a diferença estivesse registrada em lugar nenhum — agora está.O que não fiz
Não criei um
Demandas::Destroy. Sem regra de negócio para compartilhar entre web e API, seria uma classe só para embrulhar uma chamada. No dia em que houver impeditivo de verdade, a extração se paga; hoje ela só adicionaria indireção.Detalhes
Os dois lados têm fallback de mensagem:
throw :abortdevolvefalsesem popularerrors, então sem ele a tela mostraria um alerta vazio e a API, uma lista vazia. A API usa o mesmo formato de erro de#create/#update— array de strings com422.Os quatro specs novos simulam o bloqueio (dublê no retorno de
#destroy), já que introduzir um impeditivo real no model só para o teste mudaria o comportamento da aplicação. Dois cobrem o erro comunicado, dois o fallback genérico.Verificação
No container: RuboCop 110 arquivos / 0 ofensas,
zeitwerk:checkAll is good!, RSpec 388 exemplos / 0 falhas (eram 384).Nada de JS, CSS, HAML ou CSP mudou — o alerta usa o mesmo mecanismo de flash que os request specs já exercitam.