Skip to content

refactor: ajuste para exibir motivos cancelamento - #33

Open
JRaphaelO wants to merge 1 commit into
mainfrom
topic-ajuste-motivos-cancelamento
Open

refactor: ajuste para exibir motivos cancelamento#33
JRaphaelO wants to merge 1 commit into
mainfrom
topic-ajuste-motivos-cancelamento

Conversation

@JRaphaelO

Copy link
Copy Markdown
Contributor

No description provided.

@gaudinho

gaudinho Bot commented Jul 21, 2026

Copy link
Copy Markdown

✅ Review postada — #33 (review)

job_id: mintlify-docs-33-1784660141653-a348

@gaudinho gaudinho Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Melhoria sólida de documentação OpenAPI: enumera explicitamente os motivos de cancelamento (com enum no schema), lista status finais que bloqueiam o cancelamento e detalha regras de motivo por status/ator em entregas. Diff mínimo, sem impacto de código.

"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",

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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]

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant