fix: fix restify instrumentation utils that might accept undefined types

[faizhasim]

Which problem is this PR solving?

• Using restify instrumentation on middlewares that return nothing (return undefined) will break the instrumentation due to typeof undefined.then.

Short description of the changes

• This PR just add a simple defensive check on possibly undefined value.
• Additional coverage added for utils.ts

[codecov]

Codecov Report

Merging #690 (f625f8c) into main (aeadca8) will decrease coverage by 0.20%.
The diff coverage is n/a.

❗ Current head f625f8c differs from pull request most recent head 7925fab. Consider uploading reports for the commit 7925fab to get more accurate results

@@            Coverage Diff             @@
##             main     #690      +/-   ##
==========================================
- Coverage   96.82%   96.62%   -0.21%     
==========================================
  Files           9       16       +7     
  Lines         630     1036     +406     
  Branches      124      151      +27     
==========================================
+ Hits          610     1001     +391     
- Misses         20       35      +15     

Impacted Files	Coverage Δ
...opentelemetry-instrumentation-restify/src/types.ts	100.00% <0.00%> (ø)
...nstrumentation-restify/src/enums/AttributeNames.ts	100.00% <0.00%> (ø)
...try-instrumentation-restify/src/instrumentation.ts	89.32% <0.00%> (ø)
...lemetry-instrumentation-restify/test/utils.test.ts	89.28% <0.00%> (ø)
...opentelemetry-instrumentation-restify/src/utils.ts	100.00% <0.00%> (ø)
...metry-instrumentation-restify/test/restify.test.ts	99.60% <0.00%> (ø)
...telemetry-instrumentation-restify/src/constants.ts	100.00% <0.00%> (ø)

[rauno56]

👍 Good catch. I don't see a reason to install and use Bluebird though for the tests.

[faizhasim]

👍 Good catch. I don't see a reason to install and use Bluebird though for the tests.

I added that because #690 (comment). I would incline towards not including non built-in promise. I think, by now, it should be the responsibility of the custom promise author to write it according to the promise a+ spec. It might be over-stretching to also test custom promise or popular promise implementation like bluebird/rsvp/etc.

Regardless, advice me. I can modify this PR.

[rauno56]

Yeah. Really sorry to bounce you back and forth like that, but I don't think it's worth the extra dep.
As the component owner, I'd be happy to merge, once that's removed and the conflicts resolved.

[rauno56]

👍

[Flarna]

Instead of bluebird or some other promise 3rd party you could write your own promise like object in a test.
My main point is that the instrumentation explicit tests on typeof(foo.then) === "function" and not for instanceof Promise therefore I assumed this should be verified.

But I fine with removing bluebird.

[rauno56]

That makes sense, yes. The currently implemented version of the util is a bit more restrictive also checking for toString which is commonly overwritten by the promise libs - bluebird and Q do it at least. Haven't tested others.

Let's leave it for now - the current PR is solving an issue it intended to.