code-corps / code-corps/code-corps-api

StripeConnectPlanController has unhandled response cases.

Abierto
#1,031 3 comentarios 0 reacciones 0 asignados Ver en GitHub
needs clarification
Lenguaje dominante
Elixir
Estrellas
234
Forks
82
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

# Problem

This was pointed out to me while I was reviewing #1028

`StripeConnectPlanService.create`, called by the create action can return the following values:

```Elixir
{:ok, StripeConnectPlan.t}
{:error, Ecto.Changeset.t}
{:error, Stripe.APIErrorResponse.t}
{:error, :project_not_ready}
{:error, :not_found}
```

Out of those, the changeset and the `Stripe.APIErrorResponse` are handled by our `FallbackController`. The rest are not, so a 500 will be rendered due to a `ClauseError`. We should consider handling those properly.

I'm also noticing inconsistencies. `{:error, :not_found}` refers to the project. Since we have `{:error, :project_not_ready}`, `{:error, :project_not_found}` would make morse sense.

As to how we would render these, I believe it would make sense to rely on the changeset here. `:project_not_found`, really, is a `:project, :does_not_exist` validation error.

On the other hand, `:project_not_ready` would sooner fall into the category of authorization errors, or at the very least, some different level of validation, possibly even an error category of it's own.

# Steps needed in order to provide a time estimate

We should consider splitting these into separate tasks

- identify all possible responses for `CodeCorps.StripeService.StripeConnectPlanService.create`
- discuss if the responses should be mapped differently
- apply new mapping if any
- handle these responses in the controller/fallback controller

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.