GoCardless internal_server_error y request_timed_out: el fallo está en GoCardless

Qué dice GoCardless

GoCardless agrupa estos reasons en el tipo gocardless, el de los errores que se producen dentro de GoCardless: «These errors occurred within GoCardless while processing your request.». Su tabla de códigos HTTP dice esto de los dos códigos:

En la página de límites, GoCardless fija además cuánto puede durar una petición: 29 segundos («Request timeout 29 seconds»).

Tres casos que el conector no trata igual

El conector espera la respuesta de GoCardless hasta 30 segundos en cada petición. Con un cobro, un reembolso o un reintento, Odoo puede encontrarse con tres situaciones distintas:

• GoCardless contesta con un 500 o un 504, con el reason en la respuesta.
• GoCardless no contesta: la conexión se corta o se acaban los 30 segundos.
• El fallo llega al aplicar un evento, cuando el conector pide a GoCardless el pago del que habla el evento.

Lo que hace el conector

Con un 500 o un 504. El conector solo repite una petición cuando se queda sin respuesta o después de un 429. Con un 500 o un 504 sí hay respuesta, así que la da por rechazada. En un cobro, la transacción pasa a «Error» con «GoCardless rechazó la solicitud.» y, debajo, el mensaje de GoCardless con el reason y el request_id entre corchetes. La tarea de cada hora no reenvía una transacción en error. Si GoCardless llegara a crear el cobro de todos modos, su primer evento lo enlaza: cada cobro lleva en sus metadatos la referencia de la transacción de Odoo, el conector la busca con ella y le aplica el estado del pago. Una transacción en error vuelve así a «Pendiente» o pasa a «Confirmado».

Sin respuesta. El conector repite la petición una vez, con la misma clave de idempotencia. Si tampoco contesta nadie, no da el cobro por perdido: la transacción queda pendiente con «GoCardless no respondió, así que aún no se sabe si aceptó la solicitud. Se volverá a enviar, de forma segura, en menos de una hora.». La tarea de cada hora la vuelve a mandar con la misma clave; si GoCardless ya la había creado, contesta 409 y el conector adopta lo que ya existe.

Al aplicar un evento. Con cada evento de un pago, el conector pide ese pago a GoCardless. Si esa consulta falla, el webhook contesta 500 para que GoCardless vuelva a mandar el envío, y los eventos que ya se aplicaron no se aplican dos veces. La recuperación de cada hora tampoco deja atrás un evento que falló.

Los mensajes de un cobro salen en el idioma de quien lo lanza. Si lo lanza una tarea programada, como la renovación de una suscripción o el reenvío del propio conector, se escriben sin nadie delante: en una base de datos creada en castellano salen así, y en una creada en inglés y pasada después a castellano, en inglés: «GoCardless rejected the request.» y «GoCardless did not answer, so it is not known yet whether it took the request. It will be sent again, safely, within the hour.».

Qué hacer

1. Abre la transacción desde la factura, con el botón «Transacción de pago» de arriba; el menú de transacciones solo sale en modo desarrollador, y en Odoo 20 no existe. Si el mensaje nombra internal_server_error o request_timed_out, el fallo fue de GoCardless, no del cliente ni de su mandato.
2. Antes de volver a cobrar la factura, busca el cobro en el Dashboard de GoCardless: el conector pone como descripción de cada cobro la referencia de su transacción de Odoo. Si está, no cobres otra vez; su evento enlazará la transacción.
3. Si no está, vuelve a cobrar la factura con el método de pago guardado del cliente. Un cobro nuevo es otra transacción, con otra clave de idempotencia: por eso conviene mirar antes.
4. Si se repite, escribe al soporte de GoCardless con el request_id del mensaje: su documentación pide incluirlo al contactar con su soporte.

Con nuestro conector

En Odoo 17, 18, 19 y 20 el conector separa un error de GoCardless de una petición sin respuesta: el primero queda en error con su request_id, la segunda queda pendiente y se reenvía con la misma clave, y en los dos casos el evento de un cobro que sí existe lo enlaza con su transacción.

Sigue leyendo