refactor: ajuste para exibir motivos cancelamento - #33
Conversation
|
✅ Review postada — #33 (review) job_id: |
| "motivo_id": { | ||
| "type": "integer", | ||
| "description": "Motivo de cancelamento." | ||
| "description": "ID do motivo do cancelamento:\n- `1`: Tempo de espera\n- `2`: Mudança de planos\n- `3`: Acidente/veículo quebrado\n- `4`: Difícil acesso\n- `5`: Passageiro não entrou\n- `6`: Outros\n- `7`: Endereço errado\n- `8`: Corrida em andamento há mais de 24 horas\n- `9`: Falha no sistema\n- `10`: Outros casos\n- `11`: Rejeitada\n- `12`: Motorista não está vindo\n- `13`: Transação rejeitada\n- `16`: Despachado na plataforma parceira\n- `17`: Cancelado na plataforma parceira\n- `18`: Não foi possível realizar o pagamento\n- `19`: Pagamento não realizado", |
There was a problem hiding this comment.
Sugestão (nit) — a lista de motivos em /corridas/{id}/cancelar inclui IDs como 11 (Rejeitada), 13 (Transação rejeitada), 16-19 (plataforma parceira / falhas de pagamento) que parecem motivos aplicados automaticamente pelo sistema (semelhante ao que a doc de entregas descreve para cancelamento pela central). Se o consumidor externo desse endpoint não pode enviar esses IDs (só o sistema os usa internamente), valeria filtrar o enum apenas para os motivos que o cliente pode legitimamente informar — ou explicitar na descrição quais são "informáveis pelo cliente" vs. "aplicados pelo sistema". Do jeito atual, o enum sugere que qualquer um dos 17 valores é aceitável no request, o que pode induzir erro.
| "type": "integer" | ||
| "type": "integer", | ||
| "description": "ID do motivo do cancelamento. O motivo permitido varia conforme o status atual da entrega (ver descrição do endpoint):\n- `10`: Outros casos (único aceito enquanto a entrega está em despacho)\n- `12`: Motorista não está vindo (motivo de empresa)", | ||
| "enum": [10, 12] |
There was a problem hiding this comment.
Sugestão (nit) — a descrição do endpoint menciona que o motivo 10 é o único aceito enquanto a entrega está em despacho e 12 é motivo de empresa quando há condutor, mas o enum: [10, 12] no schema não distingue os contextos. Considere adicionar exemplo (example: 10) e/ou reforçar no description do campo que enviar 12 fora do contexto correto retorna erro 102, alinhando o schema com o texto explicativo do endpoint.
No description provided.