@appsignal/nodejs - npm Package Versions

3.6.1

Published on 2025-02-27.

Changed

• Update Prisma instrumentation to version 6.4. This improves compatibility with new Prisma versions. (patch 930b3db, 61316bf)

3.6.0

Published on 2025-02-24.

Changed

• e2498ad patch - Update span recognition following the OpenTelemetry Semantic Conventions 1.30 database specification. We now also sanitize SQL queries in the db.query.text attribute and Redis queries in the db.operation.name attribute.
• 282d9ac patch - Bump the log message when no span is active and one of our sample data helpers are used like setParams, setSessionData, setCustomData, etc from debug to warning.
• 753a630 patch - Update bundled trusted root certificates

Removed

• e2498ad minor - Remove the OpenTelemetry beta feature in favor of the new AppSignal collector. If you are using the AppSignal agent to send OpenTelemetry data in our public beta through the /enriched endpoint on the agent's HTTP server, please migrate to the collector to continue using the beta. The collector has a much better implementation of this feature for the beta.

3.5.5

Published on 2024-12-20.

Fixed

• Fix a performance issue when sanitising INSERT INTO ... VALUES queries. (patch 9772e93)

3.5.4

Published on 2024-11-22.

Fixed

• Allow Pino transport to be used as a transport. Before, our Pino transport could only be used as a destination:

  import pino from "pino";
  import { Appsignal, AppsignalPinoTransport } from "@appsignal/nodejs";
  
  pino(AppsignalPinoTransport({
    client: Appsignal.client,
    group: "pino"
  }));
  

  This meant it was not possible to log both to our transport and to another destination.

  Now, it is also possible to use it as a Pino transport, with the transport Pino config option or the pino.transport() function:

  import pino from "pino";
  
  pino({
    transport: {
      target: "@appsignal/nodejs/pino",
      options: {
        group: "pino"
      }
    }
  });
  

  It is no longer necessary to pass the AppSignal client to the Pino transport. AppSignal must be active for the Pino transport to work.

  By enabling its use as a transport, it is now possible to use it alongside other transports:

  pino({
    transport: {
      targets: [
        // Send logs to AppSignal...
        { target: "@appsignal/nodejs/pino" },
        // ... and to standard output!
        { target: "pino/file" }
      ]
    }
  });
  

  (patch 11b789d)

3.5.3

Published on 2024-11-07.

Added

• Set the app revision config option for Scalingo deploys automatically. If the CONTAINER_VERSION system environment variable is present, it will use used to set the revision config option automatically. Overwrite it's value by configuring the revision config option for your application. (patch 5b90b64)

Fixed

• Fix an issue where the extension fails to build on ARM64 Linux. (patch 69fcdcf)

3.5.2

Published on 2024-11-04.

Added

• e20653b patch - Add Fastify v5 compatibility

3.5.1

Published on 2024-10-16.

Added

• 46a6ad1 patch - A Pino transport is now available. If Pino is your main logger, you can now use the AppSignal pino transport to send those logs to AppSignal.

  import pino from "pino"
  import { Appsignal, AppsignalPinoTransport } from "@appsignal/nodejs"
  
  const logger = pino(
    AppsignalPinoTransport({
      client: Appsignal.client,
      group: "application",
    })
  )
  

Changed

• 1bafde8 patch - Change the primary download mirror for integrations.

3.5.0

Published on 2024-09-26.

Added

• Add support for heartbeat check-ins.

  Use the checkIn.heartbeat method to send a single heartbeat check-in event from your application. This can be used, for example, in your application's main loop:

  import { checkIn } from "@appsignal/nodejs"
  
  while (true) {
    checkIn.heartbeat("job_processor")
    await processJob()
  }
  

  Heartbeats are deduplicated and sent asynchronously, without blocking the current thread. Regardless of how often the .heartbeat method is called, at most one heartbeat with the same identifier will be sent every ten seconds.

  Pass {continuous: true} as the second argument to send heartbeats continuously during the entire lifetime of the current process. This can be used, for example, after your application has finished its boot process:

  import { checkIn } from "@appsignal/nodejs"
  
  function main() {
    checkIn.heartbeat("job_processor", {continuous: true})
    startApp()
  }
  

  (minor 839073e)

Changed

• Send check-ins concurrently. When calling Appsignal.checkIn.cron, instead of blocking the current process while the check-in events are sent, schedule them to be sent in a separate process. (patch a61d16b)
• Do not block Node.js shutdown. It is no longer necessary to call Appsignal.stop for the Node.js engine to allow itself to shut down. It should still be called and awaited in production scenarios and at the end of scripts, as it ensures that scheduled check-ins are delivered. (patch 0f438d6)

3.4.9

Published on 2024-08-14.

Changed

• Rename heartbeats to cron check-ins. Calls to Appsignal.heartbeat and Appsignal.Heartbeat should be replaced with calls to Appsignal.checkIn.cron and Appsignal.checkIn.Cron, for example:

  // Before
  import { heartbeat } from "@appsignal/nodejs"
  
  heartbeat("do_something", () => {
    do_something()
  })
  
  // After
  import { checkIn } from "@appsignal/nodejs"
  
  checkIn.cron("do_something", () => {
    do_something
  })
  

  (patch fc9abba)

Deprecated

• Calls to Appsignal.heartbeat and to the Appsignal.Heartbeat constructor will emit a deprecation warning. (patch fc9abba)

Fixed

• Prevent internal AppSignal requests from being instrumented and appearing in the "Slow API requests" panel. (patch 95bf139)

3.4.8

Published on 2024-07-04.

Fixed

• Fix different spans of the same category incorrectly being reported with the same body. (patch 100e964)