feat: added support for latest opentelemetry esm instrumentations by abhilash-sivan · Pull Request #2679 · instana/nodejs

abhilash-sivan · 2026-07-27T11:02:31Z

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

Summary

Updated @opentelemetry/instrumentation-tedious from 0.28.0 to 0.40.0.
Updated import-in-the-middle from 2.0.5 to ^3.3.3 to maintain compatibility with the newer OpenTelemetry instrumentation.
Updated @instana/instrumentation-confluent-kafka-javascript

Reason

@opentelemetry/instrumentation-tedious@0.40.0 depends on a newer @opentelemetry/instrumentation version that requires import-in-the-middle@^3. Keeping import-in-the-middle@2.x caused npm to install multiple IITM versions, which broke ESM module interception and prevented Tedious instrumentation from patching correctly.

Fix

Pinned import-in-the-middle to ^3.3.3 ensuring all instrumentation uses a single shared IITM instance, restoring ESM tracing while remaining compatible with the updated OpenTelemetry instrumentation.

PR body

bumped @opentelemetry/instrumentation-tedious from 0.28.0 to 0.40.0
bumped import-in-the-middle from 2.0.5 to 3.3.3
bumped @instana/instrumentation-confluent-kafka-javascript from 1.0.1 to 1.1.0

abhilash-sivan · 2026-07-31T12:21:21Z

-                        expect(span.data.tags['db.user']).to.eql('admin@instana@nodejs-team-db-server');
-                        expect(span.data.tags['db.statement']).to.eql(expectedStatement);
-                        expect(span.data.tags['net.peer.name']).to.eql('nodejs-team-db-server.database.windows.net');
+                        expect(span.data.tags['db.system.name']).to.eql('microsoft.sql_server');


changed assertions to adapt new semconv

The stable OpenTelemetry semantic conventions (v1.33.0+) are supported starting with @opentelemetry/instrumentation-tedious v0.39.0. See the Semantic Conventions section

And our BE supports this version already, yeah?

Yeah, BE is updated to 1.46 already. Also these are tags, shouldn't be an issue right ?

Oki Yeah I think so

kirrg001 · 2026-08-03T15:13:59Z

The problem is that Otel with ESM requires users to manually register the IITM hook.

See:
https://github.com/open-telemetry/opentelemetry-js/blob/main/doc/esm-support.md

That means, our esm-register.mjs file automatically takes care of that requirement. We need to a proper explanation to our integration + our esm register.

If we just update IITM in core with v3, we can still run into issues with Otel instrumentations who use an older instrumentations dependency. But the Otel ecosystem suffers from the same problem.

As soon as you have one Otel instrumentation which is still on the old instrumentation version, it won't work for the customer OR the instrumentation dependency got already deduped to the root (which is for example not the case for our setup - its still on 207).

Right now with the Tedious 0.40 update, all our Otel dependencies use the newer instrumentation dependency already.
So we will have problems with Customer codebases and custom Otel installations and if we allow custom otel dependencies.

As soon the customer has any slightly different installation tree and IITM v2 is on the root, the Otel instrumentations would no longer work because the Otel instrumentation dependency loads IITM as a dependency and would load v2 from the root. But we instantiate v3.

Similar to our setup: as soon as we have an Otel instrumentation which needs IITM v2, it does not work anymore.

Can you please add proper explanations & tests which break the solution? The test can just be a simple reproduce script. For now we can only update to v3 + ^.

Long-term: we may need to figure out if multiple IITM versions are being used (similar to the Otel API fix)

abhilash-sivan · 2026-08-04T09:38:06Z

The problem is that Otel with ESM requires users to manually register the IITM hook.

See: https://github.com/open-telemetry/opentelemetry-js/blob/main/doc/esm-support.md

That means, our esm-register.mjs file automatically takes care of that requirement. We need to a proper explanation to our integration + our esm register.

If we just update IITM in core with v3, we can still run into issues with Otel instrumentations who use an older instrumentations dependency. But the Otel ecosystem suffers from the same problem.

As soon as you have one Otel instrumentation which is still on the old instrumentation version, it won't work for the customer OR the instrumentation dependency got already deduped to the root (which is for example not the case for our setup - its still on 207).

Right now with the Tedious 0.40 update, all our Otel dependencies use the newer instrumentation dependency already. So we will have problems with Customer codebases and custom Otel installations and if we allow custom otel dependencies.

As soon the customer has any slightly different installation tree and IITM v2 is on the root, the Otel instrumentations would no longer work because the Otel instrumentation dependency loads IITM as a dependency and would load v2 from the root. But we instantiate v3.

Similar to our setup: as soon as we have an Otel instrumentation which needs IITM v2, it does not work anymore.

Can you please add proper explanations & tests which break the solution? The test can just be a simple reproduce script. For now we can only update to v3 + ^.

Long-term: we may need to figure out if multiple IITM versions are being used (similar to the Otel API fix)

I added a warning comment to IITM loader
https://github.com/instana/nodejs/pull/2679/changes#diff-af165377f863b6d4ad356ba4927e9b67ada30e8c4c531b4aee8c6db5c18c8e91R44

Can be deferred to debug or maybe remove entirely.

I also added a supporting test where multiple instantiations logs this warning

kirrg001 · 2026-08-04T09:42:27Z

Ty. Will check out asap

I think we have to close #2690 and merge the update both deps updates together right?

aryamohanan · 2026-08-04T10:50:34Z

+        'will not fire when another instance dispatches module load events — ' +
+        'OpenTelemetry instrumentations are likely broken. ' +
+        'To fix this, align all IITM dependencies to the same version. ' +
+        `Detected instances:\n${iitmInstances.map(p => `  - ${p}`).join('\n')}`


Do you have a sample log output showing how this warning appears? I'd like to see what it looks like in customer logs.

abhi ~/instana/nodejs [fix-tedious-esm] $ node packages/core/src/util/demo-iitm-conflict.js
{"level":30,"time":"2026-08-04T11:42:37.003Z","threadId":0,"name":"@instana/collector","msg":"PID Store starting with pid 80447"}
[WARN] [Instana] Multiple import-in-the-middle (IITM) instances detected in the module cache. This typically happens when different packages depend on incompatible IITM versions and npm deduplication places both on disk. Each instance maintains its own hook registry, so hooks registered through one instance will not fire when another instance dispatches module load events — OpenTelemetry instrumentations are likely broken. To fix this, align all IITM dependencies to the same version. Detected instances:

/Users/abhi/instana/nodejs/packages/core/node_modules/import-in-the-middle/lib/register.js

/Users/abhi/instana/nodejs/node_modules/import-in-the-middle/lib/register.js

{"level":30,"time":"2026-08-04T11:42:37.172Z","threadId":0,"name":"@instana/collector","msg":"@instana/collector module version: 6.5.0"}
{"level":30,"time":"2026-08-04T11:42:37.172Z","threadId":0,"name":"@instana/collector","msg":"Transitioning from to agentHostLookup"}
{"level":20,"time":"2026-08-04T11:42:37.175Z","threadId":0,"name":"@instana/collector","msg":"Attempt to load native add-on gcstats.js directly has been successful."}
{"level":20,"time":"2026-08-04T11:42:37.176Z","threadId":0,"name":"@instana/collector","msg":"Attempt to load native add-on event-loop-stats directly has been successful."}
{"level":30,"time":"2026-08-04T11:42:37.195Z","threadId":0,"name":"@instana/collector","msg":"Found an agent on 127.0.0.1:42699, proceeding to announce request."}
{"level":30,"time":"2026-08-04T11:42:37.195Z","threadId":0,"name":"@instana/collector","msg":"Transitioning from agentHostLookup to unannounced"}
{"level":20,"time":"2026-08-04T11:42:37.195Z","threadId":0,"name":"@instana/collector","msg":"Announcing the Node.js collector to the Instana host agent at 127.0.0.1:42699"}

It's not necessary that we add a warn log, ether we can use a debug log or just not log anything. I am okay with majority decision

Is this warning logged only once during startup, or could it be emitted more than once? I agree that we probably don't need to log this as a warning. While it can help diagnose instrumentation issues, it may be confusing or noisy for customers, especially since there's often little they can do about it directly. I'd prefer logging it at the debug level instead.

If we do keep it as a warning, I think the message should be shorter.

Yeah, debug is better.
I think iitmhook register is only happening once during startup.

I am not sure about this warning rn. We only want to see a warning when there is ITTM on the root or?

We check require.cache for multiple occurrences of import-in-the-middle's lib/register.js.

I only added this to prove the test, but I don't think we need this logic in the tracer. At best, it would run and emit debug logs, but it still wouldn't pinpoint the exact reason why an OpenTelemetry instrumentation isn't working for a customer. In practice, we also inspect the customer's package.json and dependency tree as part of the investigation.

So, I'm planning to remove both the test and this logic. I think we only need the dependency version bumps and the explanation.

aryamohanan · 2026-08-04T10:52:06Z

+
+  // Real lib/register.js entries that may be in require.cache when the full suite runs.
+  // We snapshot them before each test so we have full control over what the detector sees.
+  let snapshotKeys;


Could you please remove the unnecessary comments from the test file and keep only the ones that are essential for understanding the test logic?

aryamohanan · 2026-08-04T10:53:02Z

    "@opentelemetry/sdk-trace-base": "2.9.0",
    "cls-bluebird": "^2.1.0",
-    "import-in-the-middle": "2.0.5",
+    "import-in-the-middle": "^3.0.0",


qs: why can't we update to the latest v3.3.3?

discussed: pinning 3.3.3

kirrg001 · 2026-08-04T19:40:46Z

    "@opentelemetry/sdk-trace-base": "2.9.0",
    "cls-bluebird": "^2.1.0",
-    "import-in-the-middle": "2.0.5",
+    "import-in-the-middle": "^3.3.3",


We can switch to caret agree.

Co-authored-by: kirrg001 <katharina.irrgang@googlemail.com>

Co-authored-by: kirrg001 <katharina.irrgang@ibm.com>

sonarqubecloud · 2026-08-05T05:42:07Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

abhilash-sivan force-pushed the fix-tedious-esm branch 2 times, most recently from 6dafe24 to b5cbce4 Compare July 31, 2026 11:36

abhilash-sivan commented Jul 31, 2026

View reviewed changes

kirrg001 reviewed Aug 4, 2026

View reviewed changes

Comment thread packages/collector/esm-register.mjs Outdated

kirrg001 reviewed Aug 4, 2026

View reviewed changes

Comment thread packages/collector/esm-register.mjs Outdated

kirrg001 reviewed Aug 4, 2026

View reviewed changes

Comment thread packages/collector/esm-register.mjs Outdated

kirrg001 reviewed Aug 4, 2026

View reviewed changes

Comment thread packages/collector/esm-register.mjs Outdated

abhilash-sivan mentioned this pull request Aug 4, 2026

fix: bumped otel instrumentation and contrib test utils package instana/instrumentation-confluent-kafka-javascript#2

Merged

abhilash-sivan changed the title ~~fix: bumped @opentelemetry/instrumentation-tedious from 0.28.0 to 0.40.0~~ fix: updated otel deps and iitm Aug 4, 2026

kirrg001 reviewed Aug 4, 2026

View reviewed changes

Comment thread packages/collector/esm-register.mjs

kirrg001 reviewed Aug 4, 2026

View reviewed changes

Comment thread packages/collector/test/integration/currencies/databases/tedious/tedious-app.js Outdated

abhilash-sivan force-pushed the fix-tedious-esm branch from 322e8f4 to d0e9ecc Compare August 4, 2026 10:44

abhilash-sivan marked this pull request as ready for review August 4, 2026 10:48

abhilash-sivan requested a review from a team as a code owner August 4, 2026 10:48

abhilash-sivan mentioned this pull request Aug 4, 2026

[Prod Dependency Bot] Bumped import-in-the-middle from 2.0.5 to 3.3.2 #2690

Closed

aryamohanan reviewed Aug 4, 2026

View reviewed changes

kirrg001 reviewed Aug 4, 2026

View reviewed changes

abhilash-sivan added 8 commits August 5, 2026 10:11

fix: bumped @opentelemetry/instrumentation-tedious from 0.28.0 to 0.40.0

f04a291

chore: test

7dfdfd6

chore: bumper iitm

8e7d4df

chore: updated expectations with semconv 1.37

f880729

chore: lock file correction

e782345

chore: udpate assertions for semconv stable 1.30

73b42cb

chore: iitm

b2878f4

chore: update

1402b46

abhilash-sivan and others added 8 commits August 5, 2026 10:11

chore: update

1eb3674

chore: add comment and test for iitm

3f5978c

chore: apply suggestions from code review

6343f1f

Co-authored-by: kirrg001 <katharina.irrgang@googlemail.com>

chore: updated instr pkg and iitm

1c50d62

chore: cleanup comments

7c1dd65

chore: apply suggestion from @kirrg001

66f4108

Co-authored-by: kirrg001 <katharina.irrgang@ibm.com>

chore: update

5ebc952

chore: cleanup

eb80824

abhilash-sivan force-pushed the fix-tedious-esm branch from c7030a7 to eb80824 Compare August 5, 2026 04:41

chore: test

85520c5

kirrg001 approved these changes Aug 5, 2026

View reviewed changes

abhilash-sivan changed the title ~~fix: updated otel deps and iitm~~ feat: added support for latest opentelemetry esm instrumentations Aug 5, 2026

abhilash-sivan merged commit 3567cdd into main Aug 5, 2026
4 checks passed

Uh oh!

Conversation

abhilash-sivan commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Reason

Fix

PR body

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kirrg001 commented Aug 3, 2026

Uh oh!

abhilash-sivan commented Aug 4, 2026

Uh oh!

kirrg001 commented Aug 4, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud Bot commented Aug 5, 2026

Quality Gate passed

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

abhilash-sivan commented Jul 27, 2026 •

edited

Loading