Gracias, ese detalle adicional es útil.
Dado que estás ejecutando en ARM64, eso puede ser relevante. El soporte de contenedores ARM/aarch64 de Discourse ha tenido históricamente un manejo especial en comparación con x86_64, por lo que te recomendaría mencionarlo claramente en el título del tema o en el primer mensaje.
El resultado del plugin de IA también es interesante. Dado que la advertencia desapareció tras desactivar el plugin de IA, pero no volvió inmediatamente tras volver a activarlo, esto podría haber sido causado por alguna inicialización única, calentamiento de caché, configuración del modelo/proveedor o estado en segundo plano, en lugar de ser un error reproducible consistente del plugin.
En este punto, te sugiero seguir observando, pero si vuelve a ocurrir, intenta capturar:
- el punto final de la API y la forma del payload exactos, eliminando cualquier contenido privado;
- si la advertencia aparece solo en la primera publicación de la API tras reiniciar/reconstruir, o en cada publicación de la API;
- la duración de la solicitud del lado del cliente;
- si desactivar el plugin de IA elimina la advertencia de forma fiable en múltiples pruebas;
- si lo mismo ocurre en x86_64 o solo en ARM64, si puedes probarlo.
Para verificar la duración de la solicitud del lado del cliente, puedes usar curl con salida de temporización, por ejemplo:
curl -s -o /dev/null \
-w "total=%{time_total}s connect=%{time_connect}s starttransfer=%{time_starttransfer}s\n" \
-X POST "https://tu-sitio.ejemplo.com/posts.json" \
-H "Api-Key: TU_CLAVE_API" \
-H "Api-Username: TU_USUARIO" \
--data-urlencode "title=Prueba de temporización de API" \
--data-urlencode "raw=Pequeña publicación de prueba de API en texto plano" \
--data-urlencode "category=1"
Si la solicitud en sí tarda alrededor de 2 segundos o más, es probable que la advertencia del mutex simplemente informe que la ruta de creación de publicaciones tardó más de lo esperado por Discourse. Si la solicitud es muy rápida pero la advertencia sigue apareciendo, eso sería más interesante.
El hardware parece más que suficiente para un sitio de un solo usuario, por lo que esto podría ser específico de la arquitectura/despliegue/ruta del plugin en lugar de una simple infraestructura insuficiente.