Skip to content

Conversation

@abhilash-sivan
Copy link
Contributor

@abhilash-sivan abhilash-sivan commented Jan 14, 2026

refs https://jsw.ibm.com/browse/INSTA-70534

This PR is an extension of the following case: #2249

"An internal error happend in the Instana Node.js collector. Please contact support. TypeError: Cannot read properties of undefined (reading 'then')
at /opt/instana/instrumentation/nodejs/node_modules/@instana/core/src/tracing/instrumentation/databases/redis.js:349:28"

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.

@abhilash-sivan abhilash-sivan force-pushed the chore-safety-promise-check branch 3 times, most recently from 73c0a64 to d29bfaa Compare January 19, 2026 05:40
span.transmitManual();
});
} else {
span.d = Date.now() - span.ts;
Copy link
Contributor Author

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

Copy link
Contributor

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:

  1. promise (mostly default)
  2. callback (if lib supports callbacks)
  3. sync error (try/catch)

I assume (3) was the cause of #2249?

Copy link
Contributor Author

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.

Copy link
Contributor

@kirrg001 kirrg001 Jan 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are 5 cases:

  1. Promise (mostly default)
  2. Callback (if lib supports callbacks)
  3. Normal sync calls (usually non of our libraries uses sync calls)
  4. Validation error thrown synchronously (try/catch) -> does not even reach promise.then
  5. 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

@abhilash-sivan abhilash-sivan marked this pull request as ready for review January 19, 2026 07:02
@abhilash-sivan abhilash-sivan requested a review from a team as a code owner January 19, 2026 07:02
Copy link
Contributor

@kirrg001 kirrg001 left a 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....(...)

@abhilash-sivan
Copy link
Contributor Author

Cool.

How about we add a utility?

tracingUtil....(...)

for the following case right ?

else case added for case:
If this is not a promise, then end the span gracefully

@abhilash-sivan abhilash-sivan force-pushed the chore-safety-promise-check branch from d29bfaa to 1cbcc28 Compare January 20, 2026 05:16
@sonarqubecloud
Copy link

Quality Gate Failed Quality Gate failed

Failed conditions
76.8% Coverage on New Code (required ≥ 80%)
7.0% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

@abhilash-sivan
Copy link
Contributor Author

Cool.

How about we add a utility?

tracingUtil....(...)

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.

@abhilash-sivan
Copy link
Contributor Author

Quality Gate Failed Quality Gate failed

Failed conditions 76.8% Coverage on New Code (required ≥ 80%) 7.0% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

Only added some type checks. After merging, the coverage will be >85%

@kirrg001
Copy link
Contributor

kirrg001 commented Jan 20, 2026

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.

Yeah fine with me 👍 We can also keep as it is

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants