h: I think this will change how the dom exceptions are classified, I pushed a test to see if it would pass.

Maybe something like this would keep the best of both worlds here, could you try something like:

// same check as before
if ('stack' in (exception as Error)) {
  event = eventFromError(stackParser, exception as Error);

  // preserves the classification while adding stacktraces if it exists...
  const firstException = event.exception?.values?.[0];
  if (attachStacktrace && syntheticException && firstException && !firstException.stacktrace) {
    const frames = parseStackFrames(stackParser, syntheticException);
    if (frames.length) {
      firstException.stacktrace = { frames };
      addExceptionMechanism(event, { synthetic: true });
    }
  }
} else {
  // existing fallback
}

Thank you for the review. Your approach seems better, so I will update the PR accordingly.

This isn’t directly related to this PR, but I noticed that while the cases where the stack property is missing and where it’s an empty string are similar, the fact that whether they’re grouped under Error depends on this difference feels inconsistent. I thought it might be more accurate to determine this based on whether the class inherits from Error, as in the original PR #4156, rather than on the presence or absence of the stack property.

The stack property is not actually a standard, but more like a defacto standard but it is implemented across all browsers which is why it is a bit wonky.

I'm not familiar with the full history of this code path, but my assumption is that we are checking for the capability we need rather than asserting what the object is. In this branch, what matters is whether the exception has a stack property, not necessarily whether it inherits from Error.

Regardless, preserving grouping is important IMO, since changing this classification can affect all users. With this approach, we fix the core issue while preserving the current behavior.

I think this is a good first step. As a follow-up, we can take a closer look at the classification itself, add tests to lock down the behavior we want, and then see whether we can make these checks more semantically consistent.