Incorrect Error Grouping for java apm client v 1.13

[suikast42]

I have the same issue with the 7.6.0 stack and java apm agent 1.13.

like Incorrect Error Grouping:

The errors is grouped by the excpetion class types. The messages are not considired.

The apm java agent provides only a single captureException method.

[Sylvain_Juge]

Hi @suikast42,

Errors are grouped by exception types and stack traces, which means that two exceptions with same exception type thrown from different places will not be the same.

If those exceptions differ only by the error message, can you explain a bit the code structure that throws and captures the exceptions ? Properly chained exceptions (that are created with a cause) will result in distinct stack traces.

Also, do you have any JSON documents for such errors that have the same grouping_key but are actually different exceptions ?

[suikast42]

That's my apm testcase

        final Transaction transaction = ElasticApm.startTransaction();
        transaction.setType("custom");
        transaction.setName("Foo");
        try (Scope trScope = transaction.activate()) {

            try {
                throw new RuntimeException("In tr");
            } catch (Exception e) {
//                logger.error("In tr", e);
                transaction.captureException(e);
            }


            {
                final Span span = transaction.startSpan("a", "b", "c");
                try (Scope spnScope = span.activate()) {
                    throw new RuntimeException("In Span 1");
                } catch (Exception e) {
//                logger.error("In span", e);
                    span.captureException(e);
                } finally {
                    span.end();
                }

            }

            {
                final Span span = transaction.startSpan("a", "b", "c");
                try (Scope spnScope = span.activate()) {
                    throw new RuntimeException("In Span 2");
                } catch (Exception e) {
//                logger.error("In span", e);
                    span.captureException(e);
                } finally {
                    span.end();
                }
            }

        } finally {
            transaction.end();
        }
    }

So the stack traces are diffrent and the messages as well.

This is the result of APM view

[suikast42]

@felixbarny do you have a suggestion on this topic ?

[felixbarny (Felix Barnsteiner)]

This is a bit of a contrived example. In a real world application you would likely throw those exceptions in different methods. When you do that the exceptions have different stack traces and, hence, a different error Group ID. The message of the exception is not taken into consideration as it often contains dynamic parameters. Example form the JDK:

    static NumberFormatException forInputString(String s) {
        return new NumberFormatException("For input string: \"" + s + "\"");
    }

You wouldn't want to have different grouping keys for different inputs that have been thrown in the same method.

[suikast42]

I am not agree with that.

I can catch and log some business exceptions in the same boundary call. But they will have the same grouping key ?

[felixbarny (Felix Barnsteiner)]

If they have the same exception type, the same stack trace (including same cause), then yes, they'll have the same grouping key.

@suikast42

I can catch and log some business exceptions in the same boundary call.

In that case the exception type or stack trace would likely be different as they'd be thrown by different methods, right?

[felixbarny (Felix Barnsteiner)]

To add to that: the line number of stack traces are not considered in the grouping key. The reason is that line numbers change much more frequently in-between releases than method names. And you wouldn't want to see a new grouping key when just an empty line has been removed, for example.

[suikast42]

Ok I am agree with that now