Add support for "ignoredErrors" functionality in Sentry SDK

[dalbani]

Depends on the Sentry SDK update at #284.

[melloware]

@dalbani i just merged #285 can you update your PR to the new Config type?

[melloware]

I am going to release 2.0.8 now.

Then I will do a 2.1.0 on the latest Quarkus 3.19 and this fix as well.

[dalbani]

Isn't Quarkus 3.19 still at version CR1?

Edit: it has been released a very short time ago. It's not even mentioned on the front page on https://quarkus.io.
I was planning to use this extension with Keycloak, which is still using Quarkus 3.18.
So I now realise I'll have to wait until the next Keycloak release.

[melloware]

I can bump to 3.18.4 which is the latest 3.18 for this release. It just needs the new CONFIG stuff.

[melloware]

@all-contributors add @dalbani for code

[allcontributors]

@melloware

I've put up a pull request to add @dalbani! 🎉

[melloware]

actually it looks like i can leave it 3.15.3!

[melloware]

@dalbani 2.1.0 is in Maven Central if you want to try it.

[dalbani]

For those who might be interested in using the feature, I've run into an issue when trying to set ignored errors via QUARKUS_LOG_SENTRY_IGNORED_ERRORS.
There seems to be a bug in the Sentry whereby the so-called "external configuration" overrides the options previously set via the environment variable, instead of doing a merge.
This behaviour is probably specific to the ignoredErrors setter, where the absence of values defined in the external configuration ends up as an empty list (i.e. not a null object), thereby always overriding any previous value.
I think I will open a bug report at Sentry.

So, in the meantime, I worked around the issue by setting the "low-level" environment variable SENTRY_IGNORED_ERRORS instead.
This worked, but I'm actually surprised that it did. I was expecting Sentry to fully/only rely on the settings from quarkus-logging-sentry.
I guess that's because the SentryHandler() always sets enableExternalConfiguration to true, and then immediately calls Sentry.init(options) without giving the opportunity to disable this external configuration.
I find this behaviour of the Sentry SDK a bit strange.

By the way, as I mentioned above, the SentryHandler() constructor already calls Sentry::init(options).
Isn't the following line redundant then?

quarkus-logging-sentry/runtime/src/main/java/io/quarkus/logging/sentry/SentryHandlerValueFactory.java

Line 34 in 4e5e91c

Sentry.init(options);

[melloware]

Seems redundant to me. Wanna submit a PR?

Also did you report the original issue to the Sentry SDK team?

[melloware]

@dalbani i am new to Sentry but can you explain how breadcrumbs work?

so the docs say this

Every log statement that is greater than minimum breadcrumb level is added to Sentry scope as a breadcrumb, which can be later attached to SentryEvent if one is triggered.

So if I do this...

public String nope() {
        LOG.info("Log before throwing a runtime error!");
        sentryLogger.info("Log before throwing a runtime error!");
        throw new RuntimeException("broken");
    }

I get the Sentry error for the RuntimeException but I was expecting to see the LOG.INFO message as "breadcrumb" and I am not. So there is something I am not understanding about breadcrumbs?

[dalbani]

Also did you report the original issue to the Sentry SDK team?

I've just done it at getsentry/sentry-java#4205.

[dalbani]

@dalbani i am new to Sentry but can you explain how breadcrumbs work?

I'm not really familiar with breadcrumbs, to be honest.
I understand from https://docs.sentry.io/platforms/java/guides/jul/enriching-events/breadcrumbs/#automatic-breadcrumbs that some SDKs have this automatic breadcrumbs capability.
But I wouldn't be surprised if the Java SDK required adding breadcrumbs manually/programmatically.

[adinauer]

I get the Sentry error for the RuntimeException but I was expecting to see the LOG.INFO message as "breadcrumb" and I am not. So there is something I am not understanding about breadcrumbs?

@melloware this should be working if you set minimumBreadcrumbLevel to INFO or lower. You may also find our JUL sample helpful, but I'm not sure how well it translates into quarkus.

[melloware]

@adinauer yep I am doing exactly that let me debug futher I had the minimumBreadCrumbLevel set properly but was definitely not seeing any logs like in your JUL example above.

[adinauer]

@melloware can you attach a debugger and check minimumBreadcrumbLevel in SentryHandler.publish?

[melloware]

@adinauer yep will try and get to this today.

[melloware]

Maybe i am doing something wrong but I can see in the SentryEvent the breadCrumbs is empty

[melloware]

Here is a simple reproducer:

sentry-breadcrumb.zip

Unzip and point your DNS in application.properties

quarkus.log.sentry.dsn=http://446042f84f35fff57e40ac40f4ab4489@localhost:9000/2

Then run mvn quarkus:dev

Hit http://localhost:8080/logging-sentry/broken to fire off the exception with no bread crumbs

[dalbani]

@melloware
Would you know if/how it's possible to define the list of ignored errors as a individual environment variables?
The reason being that I have error strings which contains a comma, which is considered a separator in the literal list.
I tried the following, as explained on https://quarkus.io/guides/config-reference#environment-variables and https://stackoverflow.com/questions/73454492/how-to-pass-quarkus-list-configuration-via-environment-variable:

QUARKUS_LOG_SENTRY_IGNORED_ERRORS_0_=error1
QUARKUS_LOG_SENTRY_IGNORED_ERRORS_1_=error2

But it doesn't seem to work as the list as SentryConfig::ignoredErrors() is an empty Optional in SentryHandlerValueFactory.

The reason why I ask for environment variables specifically is that I'm using the Quarkus extension in Keycloak on Kubernetes, where environment variables are the only option I have to pass settings AFAIK.

[melloware]

@dalbani this would probably be a good @radcortez question or on the Zulip channel?

[dalbani]

Thanks for the suggestion.

I've just tried in a dummy Quarkus app where I could put the settings in application.properties:

quarkus.log.sentry.ignored-errors[0]=error1
quarkus.log.sentry.ignored-errors[1]=error2

And it did work then. So there must be magic I'm missing with environment variables.
Provided what I want is technically possible.

[radcortez]

Yes, it should work, but it seems that having the declaration:

@Deprecated(forRemoval = true)
@WithParentName
Optional<Boolean> enable();

Is causing the that env name to not be matched. I'll have a look.

In the meantime you can use the rules of environment values detailed here: https://quarkus.io/guides/config-reference#environment-variables. Just add an empty quarkus.log.sentry.ignored-errors[0] to override it with QUARKUS_LOG_SENTRY_IGNORED_ERRORS_0_

[radcortez]

smallrye/smallrye-config#1331

[melloware]

thanks @radcortez !

[dalbani]

Just add an empty quarkus.log.sentry.ignored-errors[0] to override it with QUARKUS_LOG_SENTRY_IGNORED_ERRORS_0_

Doh, of course, until I can use environment variables, I can simply pass the settings to the JVM with -Dquarkus.log.sentry.ignored-errors[0]=xxx, -Dquarkus.log.sentry.ignored-errors[1]=xxx, etc.
Thanks for the suggestion!

[radcortez]

You can still use environment variables, you just need to have the correct name of the configuration in some source like application.properties. The issue here is that when you only set QUARKUS_LOG_SENTRY_IGNORED_ERRORS_0_, we don't know if the segments should be separated with dots or dashes, so we need to do some matching with the mapping names (which has the bug in that specific scenario that I've fixed).

When a mapping is unavailable to help with the matching, you can set a quarkus.log.sentry.ignored-errors[0] in any source. This would hint the matching mechanism to disambiguate between dots and dashes and perform the matching correctly with the Env name.

So, even if the mapping matching has a bug, you can still rely on the hint matching.

[melloware]

@dalbani once you confirm and get this working can you submit a PR updating the asciidoc Guide for other users related to ignore errors?

[dalbani]

You can still use environment variables, you just need to have the correct name of the configuration in some source like application.properties.

As I mentioned above, my use case is using this extension in Keycloak on Kubernetes, where I don't have the ability to have such an application.properties file.