Issues when I enable Component, maybe Right Sidebar Blocks?

[sandra.mccollum]

I am getting some errors, have you seen these and know any solution? I thtought it was a windows memory issue, but it till happens if I have 6GB free in Windows.

On returning from a topic

On going to a topic:

These errors are intermittent, but happen quite often

Thx for any input. Not that if I try again, they usually succeed…Also, there is nothing about this in /logs

Note that I also added Featured Tiles, but if I disable Right Sidebar Blocks, the issue goes away. I have 11GB free memory and plenty of disk.

If I disable Featured Tiles and enable Right Sidebar Blocks, the issue persists.

[toanvoc (Toan Nguyen)]

I have the same error as you but I don’t know how to fix it even though I posted it here

[sandra.mccollum]

Let’s hope somebody has an idea

[thoka (Thomas Kalka)]

I would search in the browser console for errors.

[sandra.mccollum]

I got 1100 lines back, here is some of it:

2 deprecation-identify-source.js:15 DEPRECATION: Components with separately resolved templates are deprecated. Migrate to either co-located js/ts + hbs files or to gjs/gts. Tried to lookup ‘template:components/top-contributors’. [deprecation id: component-template-resolving] This will be removed in ember-source 6.0.0. See https://deprecations.emberjs.com/id/component-template-resolving

post.js:561 Using the new ‘glimmer’ post menu!
2deprecation-identify-source.js:15 DEPRECATION: Components with separately resolved templates are deprecated. Migrate to either co-located js/ts + hbs files or to gjs/gts. Tried to lookup ‘template:components/top-contributors’. [deprecation id: component-template-resolving] This will be removed in ember-source 6.0.0. See https://deprecations.emberjs.com/id/component-template-resolving

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

Discourse v3.4.0.beta4-dev — https://github.com/discourse/discourse/commits/380910aedd — Ember v5.12.0
deprecation-identify-source.js:15 DEPRECATION: Components with separately resolved templates are deprecated. Migrate to either co-located js/ts + hbs files or to gjs/gts. Tried to lookup ‘template:components/whos-online’. [deprecation id: component-template-resolving] This will be removed in ember-source 6.0.0. See https://deprecations.emberjs.com/id/component-template-resolving for more details.

[thoka (Thomas Kalka)]

@sandra.mccollum

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

This might be the cause. In this case, you are probably rate limited.
You might check the network tab of developer console, if there are more requests, when right sidebar blocks are enabled.

[sandra.mccollum]

One Question if anyone knows:

(1) I am an admin, trust level 4, so why is “DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL” not bypassing me for any rate limit?

Available settings for global rate limits and throttling

Discourse ships with 3 different global rate limits that can be configured by site admins. Global per-ip rate limits These limits apply to every unique IP address that hits the Discourse application. (files that are served directly from the filesystem or the CDN are excluded) By default this rate limit is enabled, you may disable it or set it to a reporting mode. DISCOURSE_MAX_REQS_PER_IP_MODE : default block, this rate limit applies out of the box. (other options are warn, warn+block, and n…

Global per-ip rate limits
These limits apply to every unique IP address that hits the Discourse application. (files that are served directly from the filesystem or the CDN are excluded)

By default this rate limit is enabled, you may disable it or set it to a reporting mode.

DISCOURSE_MAX_REQS_PER_IP_MODE : default block, this rate limit applies out of the box. (other options are warn, warn+block, and none)

DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE: number of requests per IP per minute (default is 200)

DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS: number of requests per IP per 10 seconds (default is 50)

DISCOURSE_MAX_ASSET_REQS_PER_IP_PER_10_SECONDS: number of asset (avatars/css) requests per IP per 10 seconds (default is 200)

DISCOURSE_MAX_REQS_RATE_LIMIT_ON_PRIVATE: should the rate limit apply to private IPs accessing Discourse? default is false.

DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL: use per user rate limits vs IP rate limits for users with this trust level or more (default 1)

To amend the limits add the desired change into your app.yml file in the env section.

I may try:

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

I also checked the nginx access log, it shows differing IP’s for our users. (I saw in a much earlier topic where this was an issue, everyone was using the same IP address for access)

[sandra.mccollum]

Even with the changes described above and after rebuilding the app, I see the rate limit warning in the browser console if I enable Right Sidebar Blocks.

How do I echo or otherwise determine the actual value of, for example: DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL

Also, if I disable the Right Sidebar Blocks, I do not see any rate limit warnings in the browser console if I traverse topics at the same rate I do with Right Sidebar Blocks enabled.

[thoka (Thomas Kalka)]

I suggest digging through search for prior discussions about rate limiting.
I’m not profound in this topic but to my understanding rate limiting is applied in two stages: first nginx does rate-limiting (not knowing about trust levels) and then the rails app does another layer of protection.

If you wish to test the hypothesis that you encounter rate limits within the nginx layer, you may comment out the following line in your app.yml:

- templates/web.ratelimited.template.yml

[sandra.mccollum]

I have no rate limits set in the nginx I use as a reverse proxy, and I will try what you suggest to see what the container is doing.

I am loading Leaderboard, Top Producers and Events in Right Sidebar Blocks.

I will report back, thx

I bet you are correct, so what are good but more lax values for these settings in /var/discourse/templates/web.ratelimited.template.yml? Is it simply trial and 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_conn_zone $binary_remote_addr zone=connperip:10m;
  limit_conn_status 429;

I bumped it to:

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

Still get the “429 Too Many Requests”

I removed Leaderboard, still get the issue.

I remove Right Sidebar Blocks, no more issue Very annoying!

Not that I do not have this issue with the Top Contributers Sidebar.

[thoka (Thomas Kalka)]

If you work from a fixed IP, you could exclude your IP from rate limiting:

Available settings for global rate limits and throttling

It looks to me like if you have the web.ratelimited.template.yml installed, then these don’t matter since stuff gets rate limited by NGINX before it gets to Discourse, right? That’s how it seems from my nginx logs. My short term solution is to add my IP address to the local IP list, so it gets past NGINX. I guess the thing to do is remove the ratelimited template to make these have any meaning?

For a first test, I would skip rate limiting completely (just don’t use web.ratelimited.template.yml)

@sandra.mccollum

I bet you are correct, so what are good but more lax values for these settings in /var/discourse/templates/web.ratelimited.template.yml? Is it simply trial and error?

You might find the origin of the requests by browsing through nginx logs:

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