✨ [RUMF-922] stack trace on handled calls

[amortemousque]

Motivation

Some errors are reported without a proper Error object. In these cases, there is no stack trace reported, making them a lot less actionable by the user. In order to enrich these errors, RUM need to generate a stack trace internally.

Changes

• Generate an handling stack on console.log
• Generate an handling stack on addError

Testing

Unit, Locally

---

I have gone over the contributing documentation.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 90.00000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 89.09%. Comparing base (9cf758d) to head (eb44532).
Report is 1710 commits behind head on main.

Files with missing lines	Patch %	Lines
packages/core/src/tools/error.ts	76.92%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #889      +/-   ##
==========================================
- Coverage   89.13%   89.09%   -0.04%     
==========================================
  Files          81       81              
  Lines        3809     3825      +16     
  Branches      850      851       +1     
==========================================
+ Hits         3395     3408      +13     
- Misses        414      417       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[bcaudan]

Instead of coupling handling stack tests with the implementation of toStackTraceString, what about directly returning a stack trace string from createHandlingStackTrace?
it would also avoid callers to do this conversion later

[amortemousque]

I'm not sure about it. I tried to be consistent with the way we handle the "normal" stack trace.

browser-sdk/packages/core/src/domain/automaticErrorCollection.ts

Lines 57 to 65 in 1f8b7c6

	function buildErrorFromParams(params: unknown[], handlingStack: StackTrace) {
	const firstErrorParam = find(params, (param: unknown): param is Error => param instanceof Error)
	return {
	message: ['console error:', ...params].map((param) => formatConsoleParameters(param)).join(' '),
	stack: firstErrorParam ? toStackTraceString(computeStackTrace(firstErrorParam)) : undefined,
	handlingStack: toStackTraceString(handlingStack),
	}
	}

Also, by looking at error.ts, it seems that the idea was to keep stack traces as StackTrace type and to be able to make transformation on them.

browser-sdk/packages/core/src/tools/error.ts

Lines 39 to 43 in 1f8b7c6

	export function formatUnknownError(
	stackTrace: StackTrace | undefined,
	errorObject: any,
	nonErrorPrefix: string,
	handlingStack?: StackTrace

Maybe I should change the test to only test the stack trace as StackTrace type and not as string. It would also make sens because the toStackTraceString has already been tested.

[bcaudan]

StackTrace is a tracekit type, it seems ok to me to keep it for tracekit API output but I'd be in favor of avoiding to use it internally if we can.

[amortemousque]

Okay done