Medium severity vulnerability introduced by a package you're using:
Line 11806 lists a dependency (axios) with a known Medium severity vulnerability. Fixing requires upgrading or replacing the dependency.

To resolve this comment:
Upgrade this dependency to at least version 0.31.0 at yarn.lock.

_{You can view more details on this finding in the Semgrep AppSec Platform here.}

Medium severity vulnerability may affect your project—review required:
Line 11806 lists a dependency (axios) with a known Medium severity vulnerability.

To resolve this comment:
Check if you have NO_PROXY configured in your environment.

• If you're affected, upgrade this dependency to at least version 0.31.0 at yarn.lock.
• If you're not affected, comment /fp we don't use this [condition]

_{You can view more details on this finding in the Semgrep AppSec Platform here.}

This is not the case when using synchronous module.registerHooks. In that case, the same hooks cover all CJS and ESM, even internal to CJS packages.

Once apm-js-collab/tracing-hooks#27 lands, we can feature detect like:

import { initialize, resolve, load } from '@apm-js-collab/tracing-hooks/hook-sync.mjs';
import Module from 'node:module';

if (runtime) {
  // ...
} else {
  // detection to decide module loader hooks to use
  // registerHooks was present but not stable until 24.13 and 25.1
  const version = (process.versions.node ?? '0.0.0')
    .split('.')
    .map(n => parseInt(n, 10));
  const stableSyncHooks = version[0] > 25 ||
    version[0] === 25 && version[1] >= 1 ||
    version[0] === 24 && version[1] >= 13;
  
  if (typeof Module.registerHooks === 'function' && stableSyncHooks) {
    initialize({ instrumentations });
    Module.registerHooks({ resolve, load });
  } else if (typeof Module.register === 'function') {

    // what you have here already, Module.register() and the cjs patch

  } else {
    throw new Error('No available API to apply module load hooks');
  }
}

updated and applied this change, seems to work well! 🎉

Missing captureException call in error handling paths

Low Severity

The startInactiveSpan call's error paths (both the channel error handler and the streamable Query's 'error' event listener) set span status to SPAN_STATUS_ERROR but never call captureException. Per the review rules, when using any startSpan API (including startInactiveSpan), error cases need to be checked and it may make sense to call captureException. This may be intentional for DB query errors (to avoid noise), but worth flagging per the rules.

 

^{Triggered by project rule: PR Review Guidelines for Cursor Bot}

^{Reviewed by Cursor Bugbot for commit 5d957bf. Configure here.}

We don't have to worry about this double wrapping.

The Orchestrion hook specifically targets module name, version and relative file path from module root. Once the code is bundled, none of the above will be able to be matched.

I guess we still want to detect if it is wrapped at all though, I guess?

The only double wrapping case we need to consider is if someone else has registered orchestrion in a hook.

Once the code is bundled, node_modules, the modules it contains and the module paths that are matched are not loaded from those locations at runtime so they will not be matched and modified by the tracing hooks.

The only double wrapping case we need to consider is if someone else has registered orchestrion in a hook.

Actually this is not entirely true. The only double wrapping we need to worry about are uses of orchestrion + tracing hooks + using the same tracing channel names as us. If we keep our channel names unique and enure we only register the hook once, the code might get wrapped by other libraries using orchestrion + tracing hooks but we will only be listening to our unique tracing channel names.

Have I written that in a comprehensible way? 🤣

None of this is required!

We probably don't need to care about supplying a hook that works with --require

ah, you mean it is good enough if everybody uses --import, even if their app is cjs?

Yeah, @isaacs did some testing came up with this ESM code that can register all the hooks:
https://github.com/apm-js-collab/tracing-hooks/#usage

--import and --require just tell Node which kind of file you are passing after the flag and we can hook everything from ESM.

Misconfiguration warnings silenced in production builds

Medium Severity

All critical misconfiguration warnings in detectOrchestrionSetup and _experimentalSetupOrchestrion are gated behind DEBUG_BUILD, which is false in production builds and tree-shaken away entirely. A user who sets _experimentalUseOrchestrion: true but forgets the --import flag or bundler plugin will silently get zero MySQL spans with no warning — the exact "silent failure" the plan document's architecture goal #4 ("Loud about misconfiguration") was designed to prevent. The runtime hooks (import-hook.mjs, require-hook.cjs) correctly use unconditional console.warn for their double-load guards, but detect.ts inconsistently gates its warnings behind DEBUG_BUILD.

 

^{Reviewed by Cursor Bugbot for commit caaf69b. Configure here.}