Problemas ao ativar o Componente, talvez Blocos da Barra Lateral Direita?

Estou recebendo alguns erros, você já viu estes e sabe alguma solução? Pensei que fosse um problema de memória do Windows, mas ainda acontece se eu tiver 6 GB livres no Windows.

Ao retornar de um tópico

Ao ir para um tópico:

Esses erros são intermitentes, mas acontecem com bastante frequência :frowning:

Obrigado por qualquer contribuição. Não que se eu tentar novamente, eles geralmente são bem-sucedidos… Além disso, não há nada sobre isso em /logs

Note que também adicionei Blocos de Destaques, mas se eu desativar os Blocos da Barra Lateral Direita, o problema desaparece. Tenho 11 GB de memória livre e bastante disco.

Se eu desativar os Blocos de Destaques e ativar os Blocos da Barra Lateral Direita, o problema persiste.

1 curtida

Eu tenho o mesmo erro que você, mas não sei como consertar, mesmo tendo postado aqui :joy: :joy: :joy:

Espero que alguém tenha uma ideia :cry:

Eu procuraria por erros no console do navegador.

Recebi 1100 linhas de volta, aqui está parte delas:

2 deprecation-identify-source.js:15 DEPRECATION: Componentes com templates resolvidos separadamente são obsoletos. Migre para arquivos js/ts + hbs co-localizados ou para gjs/gts. Tentou procurar por ‘template:components/top-contributors’. [id de deprecation: component-template-resolving] Isso será removido no ember-source 6.0.0. Veja Component Template Resolving | Ember.js - Deprecations

post.js:561 :white_check_mark: Usando o novo menu de post ‘glimmer’!
2deprecation-identify-source.js:15 DEPRECATION: Componentes com templates resolvidos separadamente são obsoletos. Migre para arquivos js/ts + hbs co-localizados ou para gjs/gts. Tentou procurar por ‘template:components/top-contributors’. [id de deprecation: component-template-resolving] Isso será removido no ember-source 6.0.0. Veja Component Template Resolving | Ember.js - Deprecations

POST https://discourse.xxxxxx.xxx/mini-profiler-resources/results 429 (Too Many Requests)

:information_source: Discourse v3.4.0.beta4-dev — Commits · discourse/discourse · GitHub — Ember v5.12.0
deprecation-identify-source.js:15 DEPRECATION: Componentes com templates resolvidos separadamente são obsoletos. Migre para arquivos js/ts + hbs co-localizados ou para gjs/gts. Tentou procurar por ‘template:components/whos-online’. [id de deprecation: component-template-resolving] Isso será removido no ember-source 6.0.0. Veja Component Template Resolving | Ember.js - Deprecations para mais detalhes.

Essa pode ser a causa. Neste caso, você provavelmente está com o limite de requisições atingido.
Você pode verificar a aba de rede do console do desenvolvedor, se houver mais requisições, quando os blocos da barra lateral direita estiverem habilitados.

1 curtida

Uma pergunta se alguém souber:

(1) Sou um administrador, nível de confiança 4, então por que “DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL” não está me isentando de nenhum limite de taxa?

Limites de taxa globais por IP
Esses limites se aplicam a cada endereço IP exclusivo que acessa a aplicação Discourse. (arquivos servidos diretamente do sistema de arquivos ou da CDN são excluídos)

Por padrão, este limite de taxa está habilitado, você pode desativá-lo ou defini-lo para um modo de relatório.

DISCOURSE_MAX_REQS_PER_IP_MODE: bloqueio padrão, este limite de taxa se aplica imediatamente. (outras opções são avisar, avisar+bloquear e nenhuma)

DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: número de requisições por IP por minuto (o padrão é 200)

DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: número de requisições por IP a cada 10 segundos (o padrão é 50)

DISCOURSE_MAX_ASSET_REQS_PER_IP_PER_10_SECONDS: número de requisições de ativos (avatares/css) por IP a cada 10 segundos (o padrão é 200)

DISCOURSE_MAX_REQS_RATE_LIMIT_ON_PRIVATE: o limite de taxa deve se aplicar a IPs privados acessando o Discourse? o padrão é falso.

DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL: usar limites de taxa por usuário em vez de limites de taxa por IP para usuários com este nível de confiança ou superior (o padrão é 1)

Para alterar os limites, adicione a alteração desejada ao seu arquivo app.yml na seção env.

Eu posso tentar:

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

Eu também verifiquei o log de acesso do nginx, ele mostra IPs diferentes para nossos usuários. (Eu vi em um tópico muito anterior onde isso era um problema, todos estavam usando o mesmo endereço IP para acesso)

Mesmo com as alterações descritas acima e após reconstruir o aplicativo, vejo o aviso de limite de taxa no console do navegador se eu habilitar os Blocos da Barra Lateral Direita.

Como eu faço para ecoar ou determinar o valor real de, por exemplo: DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL

Além disso, se eu desabilitar os Blocos da Barra Lateral Direita, não vejo nenhum aviso de limite de taxa no console do navegador se eu percorrer os tópicos na mesma taxa que faço com os Blocos da Barra Lateral Direita habilitados.

Sugiro pesquisar discussões anteriores sobre limitação de taxa.
Não sou profundo neste tópico, mas, pelo que entendi, a limitação de taxa é aplicada em dois estágios: primeiro, o nginx faz a limitação de taxa (sem saber sobre os níveis de confiança) e, em seguida, o aplicativo rails faz outra camada de proteção.

Se desejar testar a hipótese de que você encontra limites de taxa na camada nginx, você pode comentar a seguinte linha em seu app.yml:

- templates/web.ratelimited.template.yml

Não tenho limites de taxa definidos no nginx que uso como proxy reverso e tentarei o que você sugere para ver o que o contêiner está fazendo.

Estou carregando Leaderboard, Top Producers e Events em Right Sidebar Blocks.

Voltarei para reportar, obrigado.

Aposto que você está correto, então quais são valores bons, mas mais flexíveis para essas configurações em /var/discourse/templates/web.ratelimited.template.yml? É simplesmente tentativa e erro?

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;

Aumentei para:

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

Ainda recebo o “429 Too Many Requests”.

Removi o Leaderboard, ainda recebo o problema.

Removi o Right Sidebar Blocks, não há mais problema :frowning: Muito irritante!

Não que eu não tenha esse problema com o Top Contributors Sidebar.

Se você trabalha com um IP fixo, você pode excluir seu IP da limitação de taxa:

Para um primeiro teste, eu pularia completamente a limitação de taxa (apenas não use web.ratelimited.template.yml)

Você pode encontrar a origem das requisições navegando pelos logs do nginx:

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