Feature/participates e rotas - #543
Conversation
…findAll por consistencia para branch irmã
EduTiyo
left a comment
There was a problem hiding this comment.
Revisão em duas frentes (Standards e Spec) de participantes e rotas. O ponto forte: o reorder de rota (a parte difícil do spec) está certo — delete+reinsert numa transação só, com o comentário explicando o porquê, exatamente como pedido, e nenhum novo risco de join multiplicando linhas. Peço mudança por dois motivos concretos: (1) o combinado explícito com o Jordan sobre o formato de participantes/rotas na resposta não foi cumprido — há um ExpedicaoListItem duplicado e incompatível; (2) o 409 funciona, mas por comparação de substring de mensagem em português, o que o torna silenciosamente frágil a qualquer mudança de texto no adapter.
| updated_by: number | null | ||
| } | ||
|
|
||
| export interface ExpedicaoListItem extends Attributes { |
There was a problem hiding this comment.
[Spec] ExpedicaoListItem duplicado com shape incompatível. Já existe um ExpedicaoListItem em ExpedicaoCollection.ts (do Jordan, PR #540) com participantes: ParticipanteExpedicao[] ({id, nome}). Este aqui declara participantes: number[] — mesmo nome, shape diferente, em arquivo diferente. Só não quebra o build porque nada importa os dois ao mesmo tempo, mas é exatamente a inconsistência pós-rebase que o combinado "Jordan, antes de escrever código: o formato dos participantes e das rotas" existia pra evitar. Precisa reconciliar com o tipo real que o findAll usa, não criar um segundo.
| const dbError = error as { code?: string } | ||
|
|
||
| if (dbError.code === '23505') { | ||
| return Either.left(new Error('Participante já está nesta expedição.')) |
There was a problem hiding this comment.
[Standards] 409 frágil por design. A violação do unique vira um Error genérico com uma frase fixa em português, não um erro tipado (ConflictError/equivalente de domínio). O controller detecta isso via .includes('já está nesta expedição') — se essa string mudar aqui, o 409 regride pra 400/500 sem o compilador acusar nada. Vale um erro tipado (ParticipanteDuplicadoError extends InfrastructureError, no padrão de CheckViolationError/ForeignKeyViolationError já usado no PR de Eventos) em vez de comparar texto de mensagem.
|
|
||
| const result = await this.removeParticipanteUseCase.execute(Number(expedicaoId), Number(usuarioId)) | ||
|
|
||
| if (result.left()) { |
There was a problem hiding this comment.
[Standards] Mapeamento por string, mesmo padrão frágil. result.value.name === 'CollectionError' || result.value.message.includes('Falha') — funciona hoje porque o adapter só produz CollectionError ou sucesso, mas o branch "resto vira 400" é código morto: não há nenhuma condição de domínio real (expedição inexistente, participante não encontrado) modelada aqui. Mesmo comentário vale para SubstituirRotaController.ts:43.
| } | ||
| } | ||
|
|
||
| export class SubstituiRotasController implements RequestHandler { |
There was a problem hiding this comment.
[Standards] Nome do arquivo não bate com o da classe (smell). O arquivo é SubstituirRotaController.ts, mas a classe exportada é SubstituiRotasController (com S no final e verbo diferente). Pequeno, mas vale alinhar para não confundir quem for importar/procurar isso depois.
…nome do SubstituiRotaController
Adicionado os 3 endpoints relacionados a participantes e rotas: