prisma: Instrumentation error in production: `TypeError: parentTracer.getSpanLimits is not a function`

Bug description

I am attempting to connect to honeycomb.io with the new Prisma Telemetry options. In a dev environment this works just fine. But in production, I receive the following error:

TypeError: parentTracer.getSpanLimits is not a function
  at new Span (/build/node_modules/@prisma/client/runtime/index.js:21694:37)
  at /build/node_modules/@prisma/client/runtime/index.js:23527:18
  at Array.forEach (<anonymous>)
  at createSpan (/build/node_modules/@prisma/client/runtime/index.js:23511:25)
  at runMicrotasks (<anonymous>)
  at runNextTicks (node:internal/process/task_queues:61:5)
  at listOnTimeout (node:internal/timers:528:9)
  at processTimers (node:internal/timers:502:7)

How to reproduce

My code (after following these instructions: https://www.prisma.io/docs/concepts/components/prisma-client/opentelemetry-tracing#register-tracing-in-your-application)

import { NodeTracerProvider } from "@opentelemetry/sdk-trace-node";
import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-proto";
import { PrismaInstrumentation } from "@prisma/instrumentation";
import { registerInstrumentations } from "@opentelemetry/instrumentation";
import { Resource } from "@opentelemetry/resources";
import { SemanticResourceAttributes } from "@opentelemetry/semantic-conventions";
import { SimpleSpanProcessor } from "@opentelemetry/sdk-trace-base";

function setupTelemetry() {
  if (process.env.NODE_ENV !== "production") {
    return;
  }
  const provider = new NodeTracerProvider({
    resource: new Resource({
      [SemanticResourceAttributes.SERVICE_NAME]: "SERVICE_NAME"
    })
  });

  // Setup how spans are processed and exported. In this case we're sending spans
  // as we receive them to an OTLP-compatible collector (e.g. Jaeger).
  provider.addSpanProcessor(new SimpleSpanProcessor(new OTLPTraceExporter()));

  // Register your auto-instrumentors
  registerInstrumentations({
    instrumentations: [new PrismaInstrumentation()],
    tracerProvider: provider
  });

  provider.register();
  // eslint-disable-next-line no-console
  console.log("📈 Telemetry set up");
}

export default setupTelemetry;

I then import setupTelemetry at the entrypoint for my application and execute it:

import setupTelemetry from './server/telemetry.ts';
// ....
setupTelemetry();

Expected behavior

In a production environment, I should not receive an error AND I should receive telemetry data to Honeycomb. Right now, I get the aforementioned error and receive no telemetry data.

In a development (local) environment, everything behaves as expected.

Prisma information

Packages:

    "@prisma/client": "4.2.1",
    "@prisma/instrumentation": "4.2.1",
    "prisma": "4.2.1",

Environment & setup

OS: macOS (local) and Linux (Azure App Services)
Database: Azure PostgreSQL DB
Node.js version: v16.14.2 (locally and in Azure)

Prisma Version

prisma                  : 4.2.1
@prisma/client          : 4.2.1
Current platform        : darwin-arm64
Query Engine (Node-API) : libquery-engine 2920a97877e12e055c1333079b8d19cee7f33826 (at node_modules/@prisma/engines/libquery_engine-darwin-arm64.dylib.node)
Migration Engine        : migration-engine-cli 2920a97877e12e055c1333079b8d19cee7f33826 (at node_modules/@prisma/engines/migration-engine-darwin-arm64)
Introspection Engine    : introspection-core 2920a97877e12e055c1333079b8d19cee7f33826 (at node_modules/@prisma/engines/introspection-engine-darwin-arm64)
Format Binary           : prisma-fmt 2920a97877e12e055c1333079b8d19cee7f33826 (at node_modules/@prisma/engines/prisma-fmt-darwin-arm64)
Default Engines Hash    : 2920a97877e12e055c1333079b8d19cee7f33826
Studio                  : 0.469.0

About this issue

Original URL
State: open
Created 2 years ago
Reactions: 11
Comments: 30 (11 by maintainers)

Most upvoted comments

Not work:

  const provider = new NodeTracerProvider()
  const exporter = new TraceExporter()

  provider.addSpanProcessor(new SimpleSpanProcessor(exporter))

  registerInstrumentations({
    tracerProvider: provider,
    instrumentations: [
      new PrismaInstrumentation(),
      new HttpInstrumentation(),
      new FastifyInstrumentation(),
    ],
  })

Work fine:

  const provider = new NodeTracerProvider()
  const exporter = new TraceExporter()

  provider.addSpanProcessor(new SimpleSpanProcessor(exporter))
  provider.register()

  registerInstrumentations({
    instrumentations: [
      new PrismaInstrumentation(),
      new HttpInstrumentation(),
      new FastifyInstrumentation(),
    ],
  })

jvaczcorporation on Jan 24, 2024

Here’s a minimal representation of this error where I can reproduce the error:

https://github.com/SheaBelsky/prisma-instrumentation-test

Using the following Azure Services:

In this minimal environment locally, I can get Honeycomb data to work. But in production (Docker), I cannot and I get the following error:

2022-08-22T15:56:13.052368931Z /build/node_modules/@prisma/client/runtime/index.js:21694
2022-08-22T15:56:13.052433833Z     this._spanLimits = parentTracer.getSpanLimits();
2022-08-22T15:56:13.052441634Z                                     ^
2022-08-22T15:56:13.052446134Z
2022-08-22T15:56:13.052450234Z TypeError: parentTracer.getSpanLimits is not a function
2022-08-22T15:56:13.052454434Z     at new Span (/build/node_modules/@prisma/client/runtime/index.js:21694:37)
2022-08-22T15:56:13.052458634Z     at /build/node_modules/@prisma/client/runtime/index.js:23527:18
2022-08-22T15:56:13.052462834Z     at Array.forEach (<anonymous>)
2022-08-22T15:56:13.052468335Z     at createSpan (/build/node_modules/@prisma/client/runtime/index.js:23511:25)

SheaBelsky on Aug 22, 2022

On a second thought and a little bit more digging in, I think it is Prisma issue after all. We should not try to create the spans if there is no active tracer present.

SevInf on Mar 22, 2024

I still get the issue even after having installed @opentelemetry/api:

"dependencies": {
    "other": "...",
    "@opentelemetry/api": "^1.8.0",
    "@opentelemetry/exporter-trace-otlp-http": "^0.49.1",
    "@opentelemetry/instrumentation": "^0.49.1",
    "@opentelemetry/resources": "^1.22.0",
    "@opentelemetry/sdk-trace-base": "^1.22.0",
    "@opentelemetry/sdk-trace-node": "^1.22.0",
    "@opentelemetry/semantic-conventions": "^1.22.0",
    "@prisma/client": "^5.10.2",
    "@prisma/instrumentation": "^5.10.2"
},
"devDependencies": {
    "other": "...",
    "prisma": "^5.10.2"
}

TypeError: parentTracer.getSpanLimits is not a function at new Span (/Users/me/myproject/node_modules/@prisma/instrumentation/node_modules/@opentelemetry/sdk-trace-base/src/Span.ts:122:37)

Simplest way to reproduce:

import { PrismaInstrumentation } from '@prisma/instrumentation';

// =====> TypeError: parentTracer.getSpanLimits is not a function
const prismaInstrumentation = new PrismaInstrumentation();

Update

Finally, I succeeded to have it work, by setting @prisma/instrumentation to version 4.13.0.

I get the error with all the versions >= 4.14.0

So what worked for me is:

"dependencies": {
    "other": "...",
    "@opentelemetry/api": "^1.8.0",
    "@opentelemetry/exporter-trace-otlp-http": "^0.49.1",
    "@opentelemetry/instrumentation": "^0.49.1",
    "@opentelemetry/resources": "^1.22.0",
    "@opentelemetry/sdk-trace-base": "^1.22.0",
    "@opentelemetry/sdk-trace-node": "^1.22.0",
    "@opentelemetry/semantic-conventions": "^1.22.0",
    "@prisma/client": "^5.10.2",
    "@prisma/instrumentation": "4.13.0" // Upgrading this => TypeError: parentTracer.getSpanLimits is not a function
},
"devDependencies": {
    "other": "...",
    "prisma": "^5.10.2"
}

Update 2

Here is the diff between the 4.13.1 and 4.14.0 tags: https://github.com/prisma/prisma/compare/4.13.0...4.14.0

pleymor on Mar 1, 2024

I’m also experiencing this deploying to ECS after upgrading @prisma/* from 5.2.0 to 5.4.1.

thyming on Oct 12, 2023

This problem appeared on my repo because of End to End testing with Playwright on a Github Action. I can’t reproduce it locally but with the last Bump @prisma/instrumentation from 4.13.0 to 4.14.1 it exploded. OpenTelemetry is up to date but we can’t do the upgrade of @prisma/instrumentation because of that error.

Fenntasy on May 24, 2023

Still getting the same error in Azure when using ConsoleSpanExporter, and I don’t see any emitted traces in the console @danstarns

2022-09-01T13:51:45.139071054Z TypeError: parentTracer.getSpanLimits is not a function
2022-09-01T13:51:45.139088555Z     at new Span (/build/node_modules/@prisma/client/runtime/index.js:21694:37)
2022-09-01T13:51:45.139100956Z     at /build/node_modules/@prisma/client/runtime/index.js:23527:18
2022-09-01T13:51:45.139105557Z     at Array.forEach (<anonymous>)
2022-09-01T13:51:45.139110157Z     at createSpan (/build/node_modules/@prisma/client/runtime/index.js:23511:25)
2022-09-01T13:51:45.139114257Z     at runNextTicks (node:internal/process/task_queues:61:5)
2022-09-01T13:51:45.139131858Z     at listOnTimeout (node:internal/timers:528:9)
2022-09-01T13:51:45.139136359Z     at processTimers (node:internal/timers:502:7)
2022-09-01T13:51:45.291346076Z This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:

Thank you for trying this, we are looking into it.

danstarns on Sep 1, 2022

@danstarns Got it! I was able to get tracing/instrumentation logs using the Console exporter locally. I’m going to confirm that behavior in Azure App Service now, I’ll let you know how that goes.

SheaBelsky on Sep 1, 2022

@SheaBelsky Thank you for the replication. I took your docker file and then run the application, sent an HTTP request to /users - No traces in honeycomb plus I don’t get any error.

What I did find is that if I use the console exporter from open opentelemetry I do indeed see the Prisma traces. Here is what I changed to see the traces in the console:

import { NodeTracerProvider } from "@opentelemetry/sdk-trace-node";
- import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-proto";
import { PrismaInstrumentation } from "@prisma/instrumentation";
import { registerInstrumentations } from "@opentelemetry/instrumentation";
import { Resource } from "@opentelemetry/resources";
import { SemanticResourceAttributes } from "@opentelemetry/semantic-conventions";
- import { SimpleSpanProcessor } from "@opentelemetry/sdk-trace-base";
+ import { SimpleSpanProcessor, ConsoleSpanExporter } from "@opentelemetry/sdk-trace-base";

function setupTelemetry() {
  if (process.env.NODE_ENV !== "production") {
    return;
  }
  const provider = new NodeTracerProvider({
    resource: new Resource({
      [SemanticResourceAttributes.SERVICE_NAME]: "SERVICE_NAME"
    })
  });

  // Setup how spans are processed and exported. In this case we're sending spans
  // as we receive them to an OTLP-compatible collector (e.g. Jaeger).
- provider.addSpanProcessor(new SimpleSpanProcessor(new OTLPTraceExporter()));
+ provider.addSpanProcessor(new SimpleSpanProcessor(new ConsoleSpanExporter()()));

  // Register your auto-instrumentors
  registerInstrumentations({
    instrumentations: [new PrismaInstrumentation()],
    tracerProvider: provider
  });

  provider.register();
  // eslint-disable-next-line no-console
  console.log("📈 Telemetry set up");
}

export default setupTelemetry;

Can you confirm that if you enable console logging, you see the Prisma traces in the console and you don’t get the described error?

danstarns on Sep 1, 2022

@SheaBelsky thank you for the detailed help. We will look into it and see what the fix is.

garrensmith on Aug 24, 2022

@SheaBelsky one more thing. If you run the docker instance locally, do you still get the error or is it only docker running on Azure?

garrensmith on Aug 23, 2022

Will work on this today!

SheaBelsky on Aug 22, 2022

Can you maybe create a minimal Node project with Prisma and the tracing setup you are using, and see if that also causes the problem you are describing? That would make it a lot easier for us to maybe also try to deploy such a project to Azure App Services and see if that triggers the problem for us as well. Thanks @SheaBelsky.

janpio on Aug 22, 2022