getsentry / getsentry/self-hosted
/api/client-config/ endpoint spam of requests after update
- Dominant language
- Shell
- Stars
- 9.6k
- Forks
- 2k
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 15
Description
### Environment
self-hosted (https://develop.sentry.dev/self-hosted/)
### What are you trying to accomplish?
Hello.
After an update from 26.5.0 to 26.7.2 we find out an issue where a lot of requests are send to sentry to /api/client-config/ endpoint and all of them are 404. This issue started happening right after an update as our logs from Nginx proxy behind sentry confirms this.
Here is how Nginx configuration looks like
```
location / {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass http://sentry;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
}
location ~ ^/api/[0-9]+/(envelope|minidump|security)/ {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
limit_req zone=req_limit_default burst=20 nodelay;
proxy_pass http://sentry;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
}
```
It doesn't matter which page you are accessing in Sentry UI - in all of them during the page load a lot GET requests are send from my browser to /api/client-config/
Let me know in case more information is needed.
### How are you getting stuck?
It creates a lot of noise to our Nginx which is behind sentry
### Where in the product are you?
Other
### Link
_No response_
### DSN
_No response_
### Version
26.7.2
Contributor guide
Research direction
Start by reproducing a Sentry UI page load on self-hosted 26.7.2 and inspect the browser network requests for /api/client-config/. Then trace that request through the self-hosted proxy and Sentry routing configuration, comparing behavior with 26.5.0. Done means the unexpected repeated 404 requests no longer occur and the affected deployment path remains functional.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- nginx
- Domain
- infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100