Improved logging mechanism for operations on ended spans, making it easier to trace issues in both Node.js and Browser environments #5113 #5184
Conversation
…ded spans, making it easier to trace issues in both Node.js and Browser environments Reviewer: pichlermarc Refs: open-telemetry#5113
…ded spans, making it easier to trace issues in both Node.js and Browser environments Reviewer: pichlermarc Refs: open-telemetry#5113
|
👋@pichlermarc this good? |
| ); | ||
| // Adding a debug log to capture the stack trace | ||
| diag.debug(`Stack trace for ended span operation: ${new Error().stack}`); |
There was a problem hiding this comment.
Using just the stack trace string leads to dev tools not being able to apply custom formatting it does to error object - most notably the ability to jump to source code, which becomes inconsistent
// Test 1
console.log(`stack test - inline - ${new Error().stack}`);
// Test 2
console.log('stack test - arg2', new Error().stack);
// Test 3
console.log('stack test - error obj', new Error());In chrome, the experience is okay as chrome auto-linkifys links
... as long as you don't expect to use sourcemaps - you just get lead into the built file instead of the source
(realistically at otel bundle size, yeah I'll take sourcemaps thanks)
while firefox doesn't touch non-error objects
But it's also an issue when debugging node over --inspect, chrome tries it's best to find some links but only the Error object version is correct:
node --inspect-brk .\logger_test.js
(at this point it's also worth considering if it's better to change issue requirements to just change into .warn(message, Error) as diag api allows 2nd+ argument to be unknown)
No description provided.