self-hosted
self-hosted copied to clipboard
The SENTRY_URL_PREFIX setting is deprecated
Version
22.2.0.dev0
Steps to Reproduce
Install self-hosted sentry as per the guidance without changing anything.
Expected Result
No warning saying SENTRY_URL_PREFIX setting is deprecated
Actual Result
In the Sentry console I get the following banner at the top:
And clicking on that I see:
Warning text: The SENTRY_URL_PREFIX setting is deprecated. Please use SENTRY_OPTIONS['system.url-prefix'] instead.
But I don't (knowingly) use SENTRY_URL_PREFIX
anywhere. I do enter details in the initial configuration screen you get when first loading up Sentry after installation, and that field was in fact pre-populated. But I don't manually set it up anywhere else or refer to it in the config. I can't even find any reference to this env var anywhere in the repo, so I'm not sure how to proceed or what other info to provide.
Did you look for the envvar in the sentry
codebase? Any clues there? 🤔
Ah yes. But I can't see it as having been logged as an issue, unless it's hidden under something else. Shall I just ignore this warning and not make myself feel like I'm somehow doing something wrong?
You mean logged into your Sentry instance as an issue? I wouldn't expect a deprecation warning to be filed as an error.
Shall I just ignore this warning and not make myself feel like I'm somehow doing something wrong?
That, my friend, is a decision only you can make. I will support you fully either way! 😁
wouldn't expect a deprecation warning to be filed as an error
I just thought you might want to be aware of it, seeing as though this warning must by triggered by something on your side, given that so far I've done nothing except install and run the default installation. Sorry to trouble you.
Yeah, I did do some poking in sentry
for SENTRY_URL_PREFIX
. Here's where the DeprecationWarning
is coming from. However, I don't find anywhere in self-hosted
that we set SENTRY_URL_PREFIX
. You've done a grep of your filesystem to see where this might be set in your environment?
You've done a grep of your filesystem to see where this might be set in your environment?
Yep... zilch.
I know nothing about python, but isn't this bit setting SENTRY_URL_PREFIX
?
I know it comes after the legacy check you referenced, but maybe this apply_legacy_settings()
function is called again later, on settings
that now include the legacy SENTRY_URL_PREFIX
?
Interesting hypothesis, cursory ag
suggests not, but maybe?
tests/sentry/runner/test_initializer.py
4:from sentry.runner.initializer import apply_legacy_settings, bootstrap_options
168:def test_apply_legacy_settings(settings):
182: apply_legacy_settings(settings)
206: apply_legacy_settings(settings)
212: apply_legacy_settings(settings)
src/sentry/runner/initializer.py
357: apply_legacy_settings(settings)
524:def apply_legacy_settings(settings):
I can confirm we have the same issue on clean installation of Sentry 22.1.0. The same warning message appears in the UI sporadically.
I haven't set the variable anywhere in the configs. Grepping the folder on fs where our sentry lives doesn't give any clues indicating the variable would be set anywhere.
❯ ssh s.sentry.xxx
Welcome to Ubuntu 20.04.3 LTS (GNU/Linux 5.11.0-1022-aws x86_64)
Last login: Sun Feb 13 13:35:47 2022 from xxx
ubuntu@ip-172-xxx:~$ cd sentry
ubuntu@ip-172-xxx:~/sentry$ grep SENTRY_URL_PREFIX -R .
./sentry_install_log-2022-02-08_18-35-53.txt:/usr/local/lib/python3.8/site-packages/sentry/runner/initializer.py:551: DeprecatedSettingWarning: The SENTRY_URL_PREFIX setting is deprecated. Please use SENTRY_OPTIONS['system.url-prefix'] instead.
ubuntu@ip-172-xxx:~/sentry$
Same here with 22.2.0. I get the error but I don't find any occurrence of SENTRY_URL_PREFIX
except for the source code of the warning.
No recent commits or issues:
https://github.com/getsentry/sentry/search?o=desc&q=sentry_url_prefix&s=committer-date&type=commits https://github.com/getsentry/sentry/search?o=desc&q=sentry_url_prefix&s=updated&type=issues
This is gonna take some debugging. 🤔
i was not able to understand the reason, but setting system.url-prefix in config.yml got rid of this warning (which broke some monitoring scripts due to the unexpected output after sentry update :))
Thanks for the workaround @nycterent!
Leaving this open as it seems we have a (small?) bug here. Does anyone know what version this might have been introduced in? Anyone see this on 21.12.0?
Thanks for the workaround @nycterent!
Leaving this open as it seems we have a (small?) bug here. Does anyone know what version this might have been introduced in? Anyone see this on 21.12.0?
As I recall, I first saw this on 22.1.0.
Same here with 22.3.0.dev0 just installed
Or maybe it's one of these? That weren't deleted once deprecation was introduced?
https://github.com/getsentry/sentry/blob/2f31b4ef7bffdcbc80f19739fbd1a1dadaec34b1/src/sentry/options/manager.py#L149
https://github.com/getsentry/sentry/blob/2f31b4ef7bffdcbc80f19739fbd1a1dadaec34b1/src/sentry/runner/initializer.py#L576-L581
Those are where we backport the new config to the old. Current best hypothesis is that this inadvertently triggers the warning. Need to validate.
same here. After modding config,yml for the first time and restarting Sentry (docker-compose restart), we got that error consistently
We still get it. I've tried grepping / for the legacy setting. No luck.
I just got the error, on updating to Sentry 22.3.0.dev0. We did not get the error on our previous version, 21.11.0.dev0.
I dropped a line internally to see if we can get some movement on this.
Thanks for the workaround @nycterent!
Leaving this open as it seems we have a (small?) bug here. Does anyone know what version this might have been introduced in? Anyone see this on 21.12.0?
According to install_log, first warning showed between upgrade 21.12.0 -> 22.1.0 and later.
Got one taker internally and nothing jumped out. Hard to prioritize as it is mostly a minor annoyance (yes?). 🐭
I'm getting a cron email every day, so it's pretty annoying :smile: But if it's not going to be fixed quickly (as I expected), I'll apply a work around.
I'm getting a cron email every day
Ouch! 😖
I'll apply a work around
Probably the right move, I'd love to dig into this myself but I don't see that happening soon. If anyone wants to be a hero and get to the bottom of this you will get mad internet points. :P
I think this is because it can not access the routes with the given prefix.
So, I updated url-prefix with sentry's domain which is sentry.my-domain
in my case
-> Go to self-hosted/sentry/config.yml
-> Replace system.internal-url-prefix: 'http://web:9000'
with system.url-prefix: 'https://sentry.my-domain'
I'm quite sure that SENTRY_URL_PREFIX
corresponds to Admin > Settings > Root URL and that must be coming from the database because during the upgrade procedure we replace the complete file set, including config.yml
, but after the upgrade it still contains the old value.
The GUI tells us that
but I think that is simply wrong.
@chadwhitacre quite sure this is related to getsentry/sentry#31615 which changed the option store model. @markstory pointed out that these options are very different from the options being refactored this line still made it in: https://github.com/getsentry/sentry/pull/31615/files#diff-ccd3dc0900218de662c8e661fd9b2e6ade119ede4ae946043d427271e19ad420
I think reverting that line would fix the issue. This probably broke reading options from the DB which made SENTRY_OPTIONS['system.url-prefix']
which would cause issues with many existing setups. We make an API request to set this value in https://github.com/getsentry/self-hosted/blob/9bd7766dffd841166c2363b67a8e87df4c3437b2/_integration-test/run.sh#L87 so we can probably add a grep
based test in this repo to catch this regression once it is fixed.
Good find, @BYK! I guess that mention in the newsletter worked after all. 😉 😁
I certainly read the newsletter, that said you know where to find me anyways 😅
Hey @getsentry/app-backend, could I get someone to take a look at this ticket? Seems that some changes to our configuration system in https://github.com/getsentry/sentry/pull/31615 are at the very least causing spam in self-hosted, and at worst may be breaking configuration.