After I enable sentry, when a error 500 happens, the error page is not shown correctly. When I'm in 'dev' environment, the symfony debug page is not shown, as stated in the following images:

Bad:

Good:

And when I'm in 'prod' environment, my customized error page is also not shown, as stated in the following images:

Bad:

Good:

Environment

PHP 8.0 Symfony 5.2 Doctrine Migrations 3.1 sentry-symfony 4.1

Steps to Reproduce

Having the above combination completely breaks the Doctrine migrations unless we add to each migrations a method indicating that the migration is not transactional. Doctrine had this issue before (https://github.com/doctrine/migrations/issues/1104) but they fixed it with this check:

https://github.com/doctrine/migrations/blob/96c64fa17477e503da8245f14541d70d7ae76091/lib/Doctrine/Migrations/Tools/TransactionHelper.php#L39

However, sentry decorates the connection with:

Sentry\SentryBundle\Tracing\Doctrine\DBAL\TracingDriverConnection

which is obviously not a PDO instance, so the aforementioned check fails and we get a nasty error:

In TracingDriverConnection.php line 163:
                                  
  [PDOException]                  
  There is no active transaction  

Expected Result

Well obviously I expect migrations to work with and without the sentry bundle :)

Actual Result

In TracingDriverConnection.php line 163:
                                  
  [PDOException]                  
  There is no active transaction  

I've got the following problem: When I run PHPUnit on my symfony application it always exits at the same test without any exception or hint. When I run PHPUnit just for this one test where it stops everything works fine, but I get the following message:

THE ERROR HANDLER HAS CHANGED!

When I disable sentry completely then everything works fine and at the end I get some deprecation warnings. When I remove those deprecations and enable sentry again everything works. So it seems that it exits when it finds some deprecated calls.

So my question is, how can I disable sentry for the tests or is there another way to fix this issue?

DO NOT MERGE BEFORE #87!! Also wait for Symfony 4.0 release, so it will be tested in Travis CI.

This follows #89:

• [x] drop support for Symfony 2.x
• [x] support Symfony 4.x
• [x] require PHP 7.1+
• [x] thus, will leverage all the new language features (return, scalar and nullable types to start with)
• [x] wait for the release of Symfony 4, to test this in CI

Environment

How do you use Sentry?

self-hosted/on-premise 22.4.0

Which SDK and version?

• sentry/sdk 3.1.1
• sentry/sentry 3.4.0
• sentry/sentry-symfony 4.2.8
• php 7.4.28
• symfony/symfony 5.4.7

Steps to Reproduce

Enable traces_sample_rate in a development environment with web profiler / web development toolbar enabled:

sentry:
    options:
        traces_sample_rate: 1.0

Expected Result

There should only be 1 GET /_wdt/* which should return a 200 and render the web developer toolbar.

Actual Result

Enabling traces_sample_rate seems to cause GET /_wdt/* to 404 2-3 times then 200 whenever a trace runs. The final 200 loads correctly and the wdt bar is visible and functional at the bottom of the page.

traces_sample_rate: 1.0 will cause _wdt to 404 a 2-3 times on every request (usually 2).

traces_sample_rate: 0.2 will cause a _wdt 404 20% of the time.

traces_sample_rate: 0.0 will never cause a _wdt 404.

This appears to be directly related to when a trace is actually invoked.

I think that #190 should be reverted. It's restricting choices of http client, defeating the purpose of PSR-18. The benefit of reducing a supposed "complex" installation is not justified

I have my sentry set up like so:

sentry:
    dsn: '%env(SENTRY_DSN)%'
    options:
        environment: 'prod'
        release: '%env(APP_VERSION)%'
        send_default_pii: true
        excluded_exceptions:
            - Symfony\Component\HttpKernel\Exception\NotFoundHttpException

During deploy, in github actions I run a command in capistrano to fill the current release version (obviously I get the current timestamp from capistrano!):

sed -i.bak 's#%env(APP_VERSION)%#20200917133933#' ./config/packages/prod/sentry.yaml

Finally I have verified in the production environment that the release is actually set. I even made sure the replacement is done before the cache warmup.

Yet, still in Sentry no release is available... What am I missing here?

edit: I've just noticed a warning in Sentry.

It suggests the value is empty, however I have confirmed it is not. At least not in the config files on my production servers...

This is the tracing support for dbal. This also took me half a day figuring out how to make it optional to use and enable. The problem is that there is no clear way to enable tracing because there actually is no hook.

I cheated the system by replacing the symfony DbalLogger that is often used to log queries to monolog. So enabling this will actually disable that functionality. If someone else has an better idea feel free to help out I've been hitting my head on making this work better for 6 hours straight now and could not find any better way.

To use Dbal tracing you will have to enable the following options:

doctrine:
    dbal:
        logging: true

sentry:
    tracing:
        dbal_tracing: true

Good luck!

This is my initial experimental implementation of tracing. It is unfinished because it connects quite directly to the dependencies of the project.

How does it look now

I've run it on my personal pet project. Enjoy!

If you want to lint container using lint:container command it throws an error like Incompatible 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

This commit adds support to the sentry-symfony library for certain "lifecycle" events that provide, possibly simpler, extension points for some of the exception capturing process. Specifically two events: SET_USER_CONTEXT and PRE_CAPTURE.

• SET_USER_CONTEXT can be used to override the default user context that is captured in the ExceptionListener during onKernelRequest

• PRE_CAPTURE can be used to add tags, or other contents, to the client based on the event and the exception pending capture.

I've also added a "Customization" section to the README to make clear two options developers have to customize the Sentry context.

My second attempt at https://github.com/getsentry/sentry-php/pull/1439 .

Pretty much what was described in https://github.com/getsentry/sentry-symfony/issues/337#issuecomment-800920045 , eg:

sentry:
    dsn: '%env(SENTRY_DSN)%'
    register_error_listener: false
    register_error_handler: false

monolog:
    handlers:
        sentry:
            type: sentry
            level: !php/const Monolog\Logger::ERROR
            hub_id: Sentry\State\HubInterface

When forcing a warning event to Sentry I noticed that two events are sent when running in dev mode, while it is sent just once when running on prod mode.

Events from dev: https://sentry.io/organizations/dev-curumas/issues/3767108540/?project=5505764&query=is%3Aunresolved&referrer=issue-stream Note that the 1st event is marked as handled:false while the second event is marked as handled:true.

Event from prod: https://sentry.io/organizations/dev-curumas/issues/3775484061/?project=5505764&query=is%3Aunresolved&referrer=issue-stream

This event is marked as unhandled, the same way as the 1st event from dev.

Environment

Symfony: 5.4.14 Sentry Symfony SDK: v4.4.0 (not tested in the new v4.5.0). PHP: 7.4.33

Steps to Reproduce

Repro app: sentryTest.zip

1. add a sentry DSN to config/packages/sentry.yaml and .env
2. Choose one of the environment to run first (prod/dev)
3. run the server with symfony server:start
4. go to localhost/l to trigger the warning event.
5. Repeat 2-4 with the second environment.

The events are sent from the LuckyController class in src/Controller/LuckyController.php

Expected Result

just one event sent from both environments.

According to https://develop.sentry.dev/sdk/features/#http-client-integrations, we have to add the following features to the HTTP client instrumentation

• Create breadcrumbs for each outgoing request
• Set the span status to the response status code
• Add HTTP Client Errors

Environment

sentry/sdk                             3.3.0                         This is a metapackage shipping sentry/sentry with a recommended HTTP client.
sentry/sentry                          3.11.0                        A PHP SDK for Sentry (http://sentry.io)
sentry/sentry-symfony                  4.4.0                         Symfony integration for Sentry (http://getsentry.com)

Steps to Reproduce

sentry:
    register_error_listener: false
    dsn: "%env(file:SENTRY_DSN_FILE)%"
    messenger:
        enabled: true
        capture_soft_fails: false
    tracing:
        enabled: false
    options:
        environment: '%env(APP_COHORT)%'
        integrations:
            - 'Sentry\Integration\IgnoreErrorsIntegration'

services:
    Sentry\Monolog\BreadcrumbHandler:
        arguments:
            - '@Sentry\State\HubInterface'
            - !php/const Monolog\Logger::INFO

monolog:
    handlers:
        sentry_breadcrumbs:
            type: service
            name: sentry_breadcrumbs
            id: Sentry\Monolog\BreadcrumbHandler
        sentry:
            type: sentry
            level: !php/const Monolog\Logger::ERROR
            hub_id: Sentry\State\HubInterface

Expected Result

The captured error contains breadcrumbs for the current message.

Actual Result

The captured error contains breadcrumbs for all the messages prior, most of which didn't trigger a Sentry capture.

I would like to support something similar as discussed in this issue: https://github.com/getsentry/sentry-php/issues/889

• Old: Object: App\Entity\SomeEntity
• New: Object: App\Entity\SomeEntity(#123)

A solution for this would be this:

use Sentry\Serializer\Serializable;

class ExampleObject implements Serializable
{
    private $id = 123;

    public function toSentry(): array
    {
        return [
            'internal_state' => 'Object: ExampleObject(#' . $this->id . ')' ,
        ];
    }
} 

But I would rather have a more re-usable solution, via a custom Serializer:

# sentry.yaml
sentry:
  representation_serializer: App\Sentry\RepresentationSerializer

# App\Sentry\RepresentationSerializer.php

class RepresentationSerializer extends AbstractSerializer implements RepresentationSerializerInterface
{
    public function representationSerialize($value)
    {
        if (\is_object($value)) {
            return 'Object ' . \get_class($value) . '(#' . $value->getId() . ')';
        }
    }
}

For this we need to be able to pass a custom Serializer to this bundle. Would it be possible to support using a custom Serializer with the sentry-symfony bundle? https://github.com/getsentry/sentry-symfony/blob/master/src/DependencyInjection/SentryExtension.php#L123-L125