-
Notifications
You must be signed in to change notification settings - Fork 39
chore: updated instrumentations with safety check on promises #2283
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
73c0a64 to
d29bfaa
Compare
| span.transmitManual(); | ||
| }); | ||
| } else { | ||
| span.d = Date.now() - span.ts; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
else case added for case:
If this is not a promise, then end the span gracefully
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK there is three cases:
- promise (mostly default)
- callback (if lib supports callbacks)
- sync error (try/catch)
I assume (3) was the cause of #2249?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed. The 'else' case is not valid for sync error; updated accordingly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are 5 cases:
- Promise (mostly default)
- Callback (if lib supports callbacks)
- Normal sync calls (usually non of our libraries uses sync calls)
- Validation error thrown synchronously (try/catch) -> does not even reach promise.then
- Unsupported/Bug case in our instrumentation or library bug
Example for unsupported case: #2295
In this case our instrumentation had a bug where we handle the original function wrong and this resulted in an undefined return value.
For 4:
We should always send the span with the actual sync error. We do that already most of the time. Please double check for the code you have touched.
For 5:
IMO we should add a debug log (anything else could be too noisy) and we should always send the span, but with an information attached to the span? Because we miss the duration, result and errors. TBD
kirrg001
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool.
How about we add a utility?
tracingUtil....(...)
for the following case right ?
|
d29bfaa to
1cbcc28
Compare
|
This doesn’t seem very useful at the moment, because we already check for the case promise?.then === 'function' and proceed accordingly. Introducing a new common utility would keep the same checks, but would only add an extra function call without simplifying the logic. It also makes sense to leave the logic as-is, since it allows us to customize the instrumentation behavior on a case-by-case basis if needed. Centralizing this logic in a common utility doesn’t appear to make things simpler, in my opinion. |
Only added some type checks. After merging, the coverage will be >85% |
Yeah fine with me 👍 We can also keep as it is |


refs https://jsw.ibm.com/browse/INSTA-70534
This PR is an extension of the following case: #2249
The possible cause for this TypeError is a sync error, so we have to add a promise-type safety check in the missing instrumentations, and this PR handles that.