Verificación y problemas habituales - PrestaShop
El evento de prueba
En la pantalla de configuración pulsa Enviar evento de prueba. El módulo lo envía de forma sincrónica y muestra el resultado junto con su identificador, sin recargar la página; el resultado y su fecha quedan en la pantalla como indicador de estado. El evento debería aparecer en el panel, en la sección Errores del proyecto al que apunta el token.
Verificación con una excepción real
La prueba de la pantalla confirma la conexión, no la captura automática. En una tienda de pruebas provoca una excepción no gestionada - por ejemplo con un Reporter::report() temporal en tu propio módulo - y comprueba que el evento lleva entorno, hora y contexto de la petición. Borra ese código después.
Problemas habituales
El módulo se instala pero no notifica nada
Vacía la caché. PrestaShop guarda la lista de hooks enganchados en el contenedor de servicios, así que un módulo recién instalado puede quedar invisible hasta que se reconstruya el contenedor: php bin/console cache:clear o Parámetros avanzados → Rendimiento.
La tienda de pruebas informa al proyecto de producción
La tienda copiada se trajo su base de datos y con ella las credenciales. Sobrescribe la clave con la constante _DOCKRAY_PRIVATE_KEY_ en app/config/parameters.php, o pon el origen de la configuración en Solo constantes. El archivo de parámetros no forma parte de un volcado de base de datos, así que la siguiente copia no lo sobrescribirá.
He puesto una clave en el formulario pero el módulo usa otra
Normalmente hay una constante definida en app/config/parameters.php mientras el origen de la configuración está en Auto. El área de estado indica qué constantes están activas.
Los errores de JavaScript no llegan
El recolector está desactivado por defecto: activa Recoger errores de JavaScript en la configuración del módulo. Si aun así no llega nada, recuerda que el front controller responde 202 incluso cuando rechaza el informe: las barreras son el token de PrestaShop, el límite de 16 kB y 20 informes por dirección IP y minuto.
Faltan transacciones aunque los errores sí llegan
La medición de peticiones se controla por separado. Con un muestreo de transacciones igual a 0 no se produce ni una transacción: es un ajuste, no una avería.
Un mismo error se parte en muchas entradas
El panel agrupa los errores por la huella sha256(token del proyecto + tipo + mensaje). Si el mensaje contiene un número de pedido, un identificador de carrito o una marca de tiempo, cada aparición es un error distinto para el panel. Saca la parte variable del mensaje y llévala al contexto.
El panel responde 200 pero no aparece el evento
Una respuesta 200 {"success": false} significa que la cuenta ha agotado su cupo mensual de errores. La integración no lo trata como una avería, y hace bien. El cupo se ve en el panel de la cuenta; hasta fin de mes se calcula a partir del consumo registrado, así que borrar errores no lo reinicia.
Sigue sin funcionar
Repasa la lista de comprobación de falta de datos y, si no ayuda, escríbenos. Indica el nombre del proyecto, la versión de la integración y la hora aproximada de la prueba: acorta el camino a la respuesta.