Back-office colgado dos minutos por la licencia de un módulo

A finales de julio de 2026, Rekire se encontró con un back-office que, al entrar en el panel principal, se quedaba pensando y terminaba en un error 500 de tiempo agotado. La tienda, por delante, iba bien. Respuesta corta: un módulo hacía una llamada a un servidor externo sin tiempo de espera, ese servidor no respondía y PHP se quedaba esperando hasta que el servidor web cortaba la petición a los 120 segundos.

Qué estaba pasando

• Dos módulos de un tema comercial comprobaban una vez al día la licencia y las actualizaciones contra el servidor de descargas del fabricante.
• Ese servidor estaba caído de la peor forma posible: no rechazaba las conexiones, se quedaba callado. La conexión ni fallaba ni terminaba.
• La comprobación se lanzaba al entrar en el panel del back-office, así que PHP esperaba hasta que LiteSpeed mataba la petición a los 120 segundos: «500 Request Timeout».
• La web principal del fabricante respondía bien; solo el servidor de licencias estaba inaccesible. Rekire lo comprobó con curl y ping desde el propio servidor de la tienda.

Cómo encontrar algo así

1. Síntoma típico: el back-office va lento o da 500 solo en ciertas pantallas (el panel, la lista de módulos) o solo una vez al día, y el escaparate va bien.
2. Busca llamadas salientes en los módulos: grep -rln "curl_init" modules/ te da la lista de módulos que hablan con fuera.
3. Prueba el destino desde el servidor, no desde tu ordenador: curl -v --max-time 10 https://servidor-del-fabricante/. Si se queda colgado hasta los 10 segundos, ya lo tienes.
4. El registro de errores de PHP o el registro de peticiones lentas del servidor suelen indicar el fichero y la línea en la que se quedó esperando.

El arreglo: tiempos de espera cortos y no insistir

Rekire escribió al fabricante con el diagnóstico y le sugirió lo que debería hacer cualquier módulo: un tiempo de espera de 3 a 5 segundos para que una caída de su servidor no bloquee el back-office de sus clientes. Mientras tanto, parcheó la llamada con dos ideas:

• Tiempos de espera cortos: 3 segundos para conectar y 5 en total.
• Un «cortacircuitos»: si la llamada ha fallado en la última hora, no se vuelve a intentar (salvo en la página de la licencia), así que como mucho se pierden unos segundos una vez por hora.

Para quien programa módulos, el patrón queda así:

$claveFallo = 'MIMODULO_LICENCIA_FALLO';
$ultimoFallo = (int) Configuration::getGlobalValue($claveFallo);
if ($ultimoFallo && (time() - $ultimoFallo) < 3600) {
    return false; // falló hace menos de una hora: no insistas
}

$ch = curl_init($url);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 3);
curl_setopt($ch, CURLOPT_TIMEOUT, 5);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$respuesta = curl_exec($ch);
curl_close($ch);

if ($respuesta === false) {
    Configuration::updateGlobalValue($claveFallo, time());
    return false;
}

¿Se puede tocar el sistema de licencias de otro?

Lo preguntó otro miembro del grupo. La línea razonable: no saltarse la licencia, solo evitar que una caída ajena tumbe tu back-office, avisar al fabricante y apuntar el cambio, porque la próxima actualización del módulo lo borrará.

Si quieres enterarte de estos errores antes de que te los cuente nadie, el módulo Centinela de Rekire avisa por Telegram de los errores de la web, y RKR Diagnoses ayuda a ver qué módulo se come el tiempo de cada página.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación