Componentを有効化すると問題発生、Right Sidebar Blocksかも？

サポート
1

エラーが発生しています。これらのエラーを見たことがありますか、また解決策をご存知ですか？Windowsのメモリの問題かと思いましたが、Windowsで6GBの空き容量があっても発生します。

トピックから戻ったとき

エラーメッセージには、latest.jsonファイルの読み込み中にエラーが発生したことを示す悲しい顔の絵文字が表示され、戻るか再試行するかのオプションがあります。（AIによるキャプション）
エラーメッセージには、latest.jsonファイルの読み込み中にエラーが発生したことを示す悲しい顔の絵文字が表示され、戻るか再試行するかのオプションがあります。（AIによるキャプション）400×288 5.44 KB

トピックに移動したとき：

再試行ボタン付きの接続問題を示すメッセージ。（AIによるキャプション）
再試行ボタン付きの接続問題を示すメッセージ。（AIによるキャプション）690×216 15.9 KB

これらのエラーは断続的ですが、かなり頻繁に発生します:frowning:

何か情報があればよろしくお願いします。再試行すると通常は成功しますが…また、/logsには何も記載されていません。

Featured Tilesを追加しましたが、Right Sidebar Blocksを無効にすると問題は解消します。メモリは11GB空いており、ディスク容量も十分です。

Featured Tilesを無効にしてRight Sidebar Blocksを有効にすると、問題は継続します。

「いいね！」 1
3

私も同じエラーが出ていますが、どうやって修正すればいいのか分かりません。ここに投稿したのに :joy: :joy: :joy:

4

誰かがアイデアを持っていることを願っています :cry:

5

ブラウザコンソールでエラーを検索します。

6

1100行の結果が返ってきました。その一部を以下に示します。

2 deprecation-identify-source.js:15 非推奨: 別個に解決されたテンプレートを持つコンポーネントは非推奨です。共置された js/ts + hbs ファイル、または gjs/gts に移行してください。‘template:components/top-contributors’ を検索しようとしました。[非推奨 ID: component-template-resolving] これは ember-source 6.0.0 で削除されます。詳細は Component Template Resolving | Ember.js - Deprecations を参照してください。

post.js:561 :white_check_mark: 新しい「glimmer」投稿メニューを使用しています！
2deprecation-identify-source.js:15 非推奨: 別個に解決されたテンプレートを持つコンポーネントは非推奨です。共置された js/ts + hbs ファイル、または gjs/gts に移行してください。‘template:components/top-contributors’ を検索しようとしました。[非推奨 ID: component-template-resolving] これは ember-source 6.0.0 で削除されます。詳細は 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 非推奨: 別個に解決されたテンプレートを持つコンポーネントは非推奨です。共置された js/ts + hbs ファイル、または gjs/gts に移行してください。‘template:components/whos-online’ を検索しようとしました。[非推奨 ID: component-template-resolving] これは ember-source 6.0.0 で削除されます。詳細は Component Template Resolving | Ember.js - Deprecations を参照してください。

7

これが原因かもしれません。この場合、おそらくレート制限されています。
右側のサイドバーブロックが有効になっているときに、開発者コンソールのネットワークタブを確認すると、さらに多くのリクエストがあるかもしれません。

「いいね！」 1
8

質問が1つあります。もしご存知の方がいらっしゃれば：

（1）私は管理者（トラストレベル4）ですが、なぜ「DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL」がレート制限のバイパスにならないのでしょうか？

グローバルIPごとのレート制限
これらの制限は、DiscourseアプリケーションにアクセスするすべてのユニークなIPアドレスに適用されます。（ファイルシステムまたはCDNから直接提供されるファイルは除外されます）

デフォルトでは、このレート制限は有効になっています。無効にするか、レポートモードに設定することができます。

DISCOURSE_MAX_REQS_PER_IP_MODE：デフォルトはブロック。このレート制限はすぐに適用されます。（その他のオプションは、warn、warn+block、noneです）

DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE：IPあたりの1分あたりのリクエスト数（デフォルトは200）

DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS：IPあたりの10秒あたりのリクエスト数（デフォルトは50）

DISCOURSE_MAX_ASSET_REQS_PER_IP_PER_10_SECONDS：IPあたりのアセット（アバター/CSS）リクエストの10秒あたりの数（デフォルトは200）

DISCOURSE_MAX_REQS_RATE_LIMIT_ON_PRIVATE：レート制限はDiscourseにアクセスするプライベートIPに適用されますか？デフォルトはfalseです。

DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL：このトラストレベル以上のユーザーに対して、IPレート制限ではなく、ユーザーごとのレート制限を使用します（デフォルトは1）。

制限を修正するには、app.ymlファイルのenvセクションに必要な変更を追加してください。

以下を試してみます：

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

nginxのアクセスログも確認しましたが、ユーザーごとに異なるIPが表示されています。（以前のトピックで、これが問題になっており、全員が同じIPアドレスにアクセスしていたことがありました）

9

上記で説明した変更を加え、アプリを再構築した後でも、右サイドバーブロックを有効にするとブラウザコンソールにレート制限の警告が表示されます。

たとえば、DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL の実際の値をエコーまたは判別するにはどうすればよいですか？

また、右サイドバーブロックを無効にすると、右サイドバーブロックを有効にした場合と同じレートでトピックを移動しても、ブラウザコンソールにレート制限の警告は表示されません。

10

レート制限に関する過去の議論を検索することをお勧めします。
このトピックについては詳しくありませんが、私の理解では、レート制限は2段階で適用されます。まず、nginxがレート制限を行い（信頼レベルは認識しません）、次にRailsアプリが別の保護レイヤーを適用します。

nginxレイヤー内でレート制限に遭遇するという仮説をテストしたい場合は、app.ymlの次の行をコメントアウトできます。

- templates/web.ratelimited.template.yml
11

リバースプロキシとして使用しているnginxにレート制限は設定していません。コンテナが何をしているか確認するために、ご提案いただいたことを試してみます。

ライトサイドバーブロックにリーダーボード、トッププロデューサー、イベントをロードしています。

また報告します。ありがとうございます。

おそらく正しいのでしょう。では、/var/discourse/templates/web.ratelimited.template.yml のこれらの設定について、より緩やかな値はありますか？単なる試行錯誤ですか？

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;

私はこれを以下のように増やしました：

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

それでも「429 Too Many Requests」が表示されます。

リーダーボードを削除しましたが、問題は発生します。

ライトサイドバーブロックを削除すると、問題はなくなりました :frowning: とても迷惑です！

トップコントリビューターサイドバーでこの問題が発生しないわけではありません。

12

固定IPアドレスから作業している場合は、IPアドレスをレート制限から除外できます。

最初のテストとしては、レート制限を完全にスキップすることをお勧めします（web.ratelimited.template.ymlを使用しないだけです）。

nginxのログをブラウズすることで、リクエストの発生源を見つけることができるかもしれません。

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