-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lint:container throws an error if dsn is configured as an env variable #303
Comments
The root of the issue seems to be here: symfony/symfony#20850 (comment)
But nowhere in this bundle we instantiate the |
|
It seems that some service is triggering the chain of instantiation, I see multiple |
service |
Ok, so I fear that the issue is not solvable... The listener is used to attach Sentry to console commands, which It's the same vicious cycle that you have when doing |
when doing |
@nicolas-grekas any suggestion here? Is this solvable in any way? |
I don't have enough insights to be helpful, a reproducer would be a good start. BTW, installing the package adds a bunch of guzzle+psr+php-http packages... what a mess... :) |
The suggested transport is Guzzle, but you can replace to use anything you want, Symfony Client included. To reproduce, probably adding this config and then run sentry:
dsn: "%env(SENTRY_DSN)%" |
That's what the recipe installs by default - and when I cannot reproduce, so that's not enough.
It's more than suggested: it's a required dependency of |
i can confirm that just by installing the bundle i can't reproduce it. error occurs on my application on sf4.4. i'm now trying to reproduce it on fresh installation of symfony |
Ok so problem is when linter finds an error. It throws exception which sentry bundle is trying to send but it can't because of? This is the place i don't know why it can't, probably doing |
Oh understood! So the listener (and in turn Sentry's |
Correct, but problem is You don't know what errors have to be solved ;) |
It's designed to catch any error in console commands too, but I don't know how you could disable this behavior in any way without risking to alter inadvertently the behavior in prod too. |
Closing as this seems to be not fixable. I can also add this:
Since newer version of Sentry server, you can use the new DSN which does no longer contains secret values, so hardcoding it in the YAML config is now doable. |
If you want to lint container using
lint:container
command it throws an error likeIncompatible use of dynamic environment variables "SENTRY_DSN" found in parameters.
caused by another error
The option "dsn" with value "%env(SENTRY_DSN)%" is invalid.
coming from
vendor/sentry/sentry/src/Options.php:74
the strange thing is that bundle work fine with dsn from env variable, perfectly clears cache etc.
only linting container throws that error
it is not critical but DSN as env variable is very required thing because if you have many environments you can't just hard code dsn into yaml config
for now we can't run container linter during CI/CD process
The text was updated successfully, but these errors were encountered: