Problemas cuando habilito el componente, ¿quizás bloques de la barra lateral derecha?

Estoy recibiendo algunos errores, ¿los has visto y conoces alguna solución? Pensé que era un problema de memoria de Windows, pero todavía ocurre si tengo 6 GB libres en Windows.

Al regresar de un tema

Al ir a un tema:

Estos errores son intermitentes, pero ocurren con bastante frecuencia :frowning:

Gracias por cualquier aporte. No es que si lo intento de nuevo, suelen tener éxito… Además, no hay nada sobre esto en /logs

Tenga en cuenta que también agregué Featured Tiles, pero si deshabilito Right Sidebar Blocks, el problema desaparece. Tengo 11 GB de memoria libre y mucho espacio en disco.

Si deshabilito Featured Tiles y habilito Right Sidebar Blocks, el problema persiste.

1 me gusta

Tengo el mismo error que tú, pero no sé cómo solucionarlo aunque lo publiqué aquí :joy: :joy: :joy:

Esperemos que alguien tenga una idea :cry:

Buscaría errores en la consola del navegador.

Recibí 1100 líneas, aquí hay una parte:\n\n2 deprecation-identify-source.js:15 DEPRECACIÓN: Los componentes con plantillas resueltas por separado están obsoletos. Migra a archivos js/ts + hbs co-ubicados o a gjs/gts. Se intentó buscar ‘template:components/top-contributors’. [id de deprecación: component-template-resolving] Esto se eliminará en ember-source 6.0.0. Ver Component Template Resolving | Ember.js - Deprecations \n\npost.js:561 :white_check_mark: ¡Usando el nuevo menú de publicaciones ‘glimmer’!\n2deprecation-identify-source.js:15 DEPRECACIÓN: Los componentes con plantillas resueltas por separado están obsoletos. Migra a archivos js/ts + hbs co-ubicados o a gjs/gts. Se intentó buscar ‘template:components/top-contributors’. [id de deprecación: component-template-resolving] Esto se eliminará en ember-source 6.0.0. Ver Ember.js - Deprecations https://discourse.xxxxxx.xxx/mini-profiler-resources/results 429 (Demasiadas solicitudes)\n\nℹ️ Discourse v3.4.0.beta4-dev — Commits · discourse/discourse · GitHub — Ember v5.12.0\ndeprecation-identify-source.js:15 DEPRECACIÓN: Los componentes con plantillas resueltas por separado están obsoletos. Migra a archivos js/ts + hbs co-ubicados o a gjs/gts. Se intentó buscar ‘template:components/whos-online’. [id de deprecación: component-template-resolving] Esto se eliminará en ember-source 6.0.0. Ver Component Template Resolving | Ember.js - Deprecations para más detalles.

Esta podría ser la causa. En este caso, probablemente se te esté limitando la velocidad.
Es posible que revises la pestaña de red de la consola del desarrollador, si hay más solicitudes, cuando los bloques de la barra lateral derecha están habilitados.

1 me gusta

Una pregunta si alguien sabe:

(1) Soy administrador, nivel de confianza 4, ¿por qué “DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL” no me exime de ningún límite de tasa?

Límites de tasa globales por IP
Estos límites se aplican a cada dirección IP única que accede a la aplicación Discourse. (se excluyen los archivos que se sirven directamente desde el sistema de archivos o la CDN)

Por defecto, este límite de tasa está habilitado, puedes deshabilitarlo o configurarlo en modo de reporte.

DISCOURSE_MAX_REQS_PER_IP_MODE: bloqueo por defecto, este límite de tasa se aplica de inmediato. (otras opciones son advertir, advertir+bloquear y ninguna)

DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: número de solicitudes por IP por minuto (el valor predeterminado es 200)

DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: número de solicitudes por IP por 10 segundos (el valor predeterminado es 50)

DISCOURSE_MAX_ASSET_REQS_PER_IP_PER_10_SECONDS: número de solicitudes de activos (avatares/css) por IP por 10 segundos (el valor predeterminado es 200)

DISCOURSE_MAX_REQS_RATE_LIMIT_ON_PRIVATE: ¿debería aplicarse el límite de tasa a las IPs privadas que acceden a Discourse? el valor predeterminado es falso.

DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL: usar límites de tasa por usuario en lugar de límites de tasa por IP para usuarios con este nivel de confianza o superior (predeterminado 1)

Para modificar los límites, agrega el cambio deseado en tu archivo app.yml en la sección env.

Puede que intente:

DISCOURSE_MAX_REQS_PER_IP_MODE: warn
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: 600
DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: 200
DISCOURSE_MAX_ASSET_REQS_PER_IP_PER_10_SECONDS: 400
DISCOURSE_MAX_REQS_RATE_LIMIT_ON_PRIVATE: false
DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL: 2

También revisé el log de acceso de nginx, muestra IPs diferentes para nuestros usuarios. (Vi en un tema mucho anterior donde este era un problema, todos usaban la misma dirección IP para acceder)

Incluso con los cambios descritos anteriormente y después de reconstruir la aplicación, veo la advertencia de límite de velocidad en la consola del navegador si habilito los Bloques de Barra Lateral Derecha.

¿Cómo imprimo o determino de otra manera el valor real de, por ejemplo: DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL?

Además, si deshabilito los Bloques de Barra Lateral Derecha, no veo ninguna advertencia de límite de velocidad en la consola del navegador si navego por los temas a la misma velocidad que lo hago con los Bloques de Barra Lateral Derecha habilitados.

Sugiero buscar en las discusiones anteriores sobre limitación de velocidad.
No soy un experto en este tema, pero según mi entendimiento, la limitación de velocidad se aplica en dos etapas: primero, nginx realiza la limitación de velocidad (sin conocer los niveles de confianza) y luego la aplicación de Rails realiza otra capa de protección.

Si deseas probar la hipótesis de que encuentras límites de velocidad dentro de la capa de nginx, puedes comentar la siguiente línea en tu app.yml:

- templates/web.ratelimited.template.yml

No tengo límites de tasa establecidos en el nginx que uso como proxy inverso, e intentaré lo que sugieres para ver qué está haciendo el contenedor.

Estoy cargando Leaderboard, Top Producers y Events en los bloques de la barra lateral derecha.

Informaré, gracias.

Apuesto a que tienes razón, así que ¿cuáles son valores buenos pero más laxos para estas configuraciones en /var/discourse/templates/web.ratelimited.template.yml? ¿Es simplemente prueba y error?

params:
reqs_per_second: 12
burst_per_second: 12
reqs_per_minute: 200
burst_per_minute: 100
conn_per_ip: 20

run:

  • replace:
    filename: “/etc/nginx/conf.d/discourse.conf”
    from: /server.+{/
    to: |
    limit_req_zone $binary_remote_addr zone=flood:10m rate=$reqs_per_secondr/s;
    limit_req_zone $binary_remote_addr zone=bot:10m rate=$reqs_per_minuter/m;
    limit_req_status 429;
    limit_req_zone $binary_remote_addr zone=connperip:10m;
    limit_conn_status 429;

Lo aumenté a:

reqs_per_second: 18
burst_per_second: 18
reqs_per_minute: 400
burst_per_minute: 200
conn_per_ip: 20

Todavía obtengo el “429 Demasiadas solicitudes”.

Eliminé Leaderboard, todavía obtengo el problema.

Elimino los bloques de la barra lateral derecha, no más problemas :frowning: ¡Muy molesto!

No es que no tenga este problema con la barra lateral de Top Contributors.

Si trabajas desde una IP fija, podrías excluir tu IP del límite de velocidad:

Para una primera prueba, omitiría por completo el límite de velocidad (simplemente no uses web.ratelimited.template.yml)

Podrías encontrar el origen de las solicitudes navegando por los registros de nginx:

./launcher enter app
less /var/log/nginx/access.log