Assigned
Status Update
No update yet.
Comments
mu...@google.com
If you are constructing your errors with newlines, lets say ErrorType<string>\nRequestId:<id>\nTime:<timestamp> , have you tried to either strip the newline characters or avoid including additional content in the error message. The reason for that is Stackdriver Error Reporting is not built to handle content between the ErrorType and the actual stack. Let me know.
an...@gmail.com
Actually, I’m not constructing the error myself. It is thrown from the modules I'm using. As you can see in the provided stack traces, it’s @google-cloud and axios modules respectively.
I am not sure whether I followed your request properly.
aa...@google.com
al...@google.com
In terms of the process of grouping, we need to conciser the following steps that are taken before and during grouping staging:
https://cloud.google.com/error-reporting/docs/grouping-errors
Step 1: Before grouping
Before Error Reporting evaluates any error for grouping, it decides the following:
a. On App Engine standard environment, errors logged with a severity lower than ERROR are ignored.
b. Stack frames which are not owned by the user are ignored (for instance, those that belong to public libraries).
c. Any repeating sequence of one or more stack frames is replaced by a single occurrence of that sequence.
d. Compiler-introduced methods and symbols are removed.
Step 2: Grouping
When the system is evaluating errors, it follows these general patterns:
a. Exceptions are grouped together if they have the same exception type and similar stacks.
b. The stack trace is ignored for exceptions that are typically unrelated to the source location where they occur.
c. Errors without an exception stack are grouped together if they were created by the same log statement, approximated by the source location it was reported from (reportLocation).
In your case, it would seem that the reason why these stack traces were grouped together is for the system following the pattern in Step 2, c, where errors without an exception stack are grouped together if they were created by the same log statement, approximated by the source location it was reported from (reportLocation). In this case, the stack trace were in the same source location which in this example, it was in the location of "/workspace/node_modules/@google-cloud/common/build/src/" if I am not mistaken.
I believe the issue here is that it begins not in before grouping, but when the grouping starts.
Step 1: Before grouping
Before Error Reporting evaluates any error for grouping, it decides the following:
a. On App Engine standard environment, errors logged with a severity lower than ERROR are ignored.
b. Stack frames which are not owned by the user are ignored (for instance, those that belong to public libraries).
c. Any repeating sequence of one or more stack frames is replaced by a single occurrence of that sequence.
d. Compiler-introduced methods and symbols are removed.
Step 2: Grouping
When the system is evaluating errors, it follows these general patterns:
a. Exceptions are grouped together if they have the same exception type and similar stacks.
b. The stack trace is ignored for exceptions that are typically unrelated to the source location where they occur.
c. Errors without an exception stack are grouped together if they were created by the same log statement, approximated by the source location it was reported from (reportLocation).
In your case, it would seem that the reason why these stack traces were grouped together is for the system following the pattern in Step 2, c, where errors without an exception stack are grouped together if they were created by the same log statement, approximated by the source location it was reported from (reportLocation). In this case, the stack trace were in the same source location which in this example, it was in the location of "/workspace/node_modules/@google-cloud/common/build/src/" if I am not mistaken.
I believe the issue here is that it begins not in before grouping, but when the grouping starts.
an...@gmail.com
I believe Step 2c is not relevant, because it's about “Errors without an exception stack”, whereas in my case all the errors are with exception stacks.
aa...@google.com
Hello, I have opened an internal investigation with our Error Reporting product team in regards to this and I have also linked the internal investigation to this. They will update this PIT.
Feel free to post here should you have any additional comments or concerns regarding the issue Nevertheless, rest assured that your feedback is always taken seriously.
Feel free to post here should you have any additional comments or concerns regarding the issue Nevertheless, rest assured that your feedback is always taken seriously.
[Deleted User] <[Deleted User]>
Hello,
Are there any updates on this issue? I know this is old issue, but it is still happening right now. Basically the top stack frames are ignored if they are from "node_modules" so all the errors that have similar stackframes at the very bottom gets grouped together. I get why it is grouped by Error Type and not the message, but for JavaScript almost all the errors are of type "Error". This is especially true for third-party library thrown errors, and we have no control over. Perhaps some settings can be provided so there is a way to group by error message? (the message is always on the first line)
Are there any updates on this issue? I know this is old issue, but it is still happening right now. Basically the top stack frames are ignored if they are from "node_modules" so all the errors that have similar stackframes at the very bottom gets grouped together. I get why it is grouped by Error Type and not the message, but for JavaScript almost all the errors are of type "Error". This is especially true for third-party library thrown errors, and we have no control over. Perhaps some settings can be provided so there is a way to group by error message? (the message is always on the first line)
Description
Problem
Unrelated errors were grouped together.
Stack trace sample (from the Error Details):
Two other stack traces that incorrectly were grouped with this.
Screenshots are attached.
Expectations
It is expected that error grouping would take the error message into account and would not group errors with absolutely different messages. I have consultedhttps://cloud.google.com/error-reporting/docs/grouping-errors and I believe that the grouping is not correct for this particular example.
Guess
Here are my guesses on the cause.
Error.at process._tickCallback (next_tick.js:68), is very similar for all the traces. And this frame is shown in the “Show less” mode. Thus, perhaps it’s influencing how the errors are being grouped. This is contradicting the statement from the documentation, “Stack frames which are not owned by the user are ignored.”This issue may be a bit related to