feat(node): Add LangChain v1 support

[RulaKhaled]

This PR adds support for LangChain v1.

Changes

• LangChain v1 Response Metadata Extraction

  • Updated response attribute extraction to support LangChain v1's different data structure:

• Instrument ConfigurableModel from chat_models/universal.cjs

Quick context:

The initChatModel unified API (introduced in LangChain v1) was not being instrumented in CJS applications. This happened because:

1. initChatModel uses dynamic import() to load providers (even in CJS mode)
2. OpenTelemetry's CJS instrumentation only hooks require(), not dynamic import()
3. Provider packages like @langchain/openai were never being patched when loaded via initChatModel

Solution: Added instrumentation for the main langchain package. When langchain/dist/chat_models/universal.cjs is loaded, we patch the ConfigurableModel prototype. Since initChatModel returns a ConfigurableModel instance, it inherits the patched methods regardless of how the provider is loaded.

This fix ensures initChatModel works in CJS applications without requiring users to manually import provider packages.

• Add tests for node integrations tests testing v1 changes
• All existing tests continue to pass
• New v1 test suite validates:
  • Basic chat model spans with and without PII
  • Tool call instrumentation
  • Message truncation behavior
  • Timing issues with pre-imported clients
  • initChatModel API with OpenAI (now working in both ESM and CJS)

Closes https://linear.app/getsentry/issue/JS-1071/support-langchain-v1

[linear]

JS-1071 Support LangChain v1

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	24.8 kB	-	-
@sentry/browser - with treeshaking flags	23.31 kB	-	-
@sentry/browser (incl. Tracing)	41.54 kB	-	-
@sentry/browser (incl. Tracing, Profiling)	46.13 kB	-	-
@sentry/browser (incl. Tracing, Replay)	79.96 kB	-	-
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	69.69 kB	-	-
@sentry/browser (incl. Tracing, Replay with Canvas)	84.64 kB	-	-
@sentry/browser (incl. Tracing, Replay, Feedback)	96.88 kB	-	-
@sentry/browser (incl. Feedback)	41.48 kB	-	-
@sentry/browser (incl. sendFeedback)	29.49 kB	-	-
@sentry/browser (incl. FeedbackAsync)	34.43 kB	-	-
@sentry/react	26.52 kB	-	-
@sentry/react (incl. Tracing)	43.74 kB	-	-
@sentry/vue	29.25 kB	-	-
@sentry/vue (incl. Tracing)	43.34 kB	-	-
@sentry/svelte	24.82 kB	-	-
CDN Bundle	27.17 kB	-	-
CDN Bundle (incl. Tracing)	42.16 kB	-	-
CDN Bundle (incl. Tracing, Replay)	78.7 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback)	84.16 kB	-	-
CDN Bundle - uncompressed	79.84 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	125.22 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	241.25 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	254.01 kB	-	-
@sentry/nextjs (client)	45.96 kB	-	-
@sentry/sveltekit (client)	41.9 kB	-	-
@sentry/node-core	51.19 kB	+0.01%	+1 B 🔺
@sentry/node	159.36 kB	+0.08%	+117 B 🔺
@sentry/node - without tracing	92.83 kB	+0.01%	+1 B 🔺
@sentry/aws-serverless	108.08 kB	+0.01%	+1 B 🔺

View base workflow run

[github-actions]

node-overhead report 🧳

Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,727	-	9,086	-4%
GET With Sentry	1,770	20%	1,761	+1%
GET With Sentry (error only)	6,172	71%	6,153	+0%
POST Baseline	1,186	-	1,210	-2%
POST With Sentry	597	50%	597	-
POST With Sentry (error only)	1,045	88%	1,075	-3%
MYSQL Baseline	3,321	-	3,326	-0%
MYSQL With Sentry	450	14%	493	-9%
MYSQL With Sentry (error only)	2,702	81%	2,708	-0%

View base workflow run

[nicohrubec]

Makes sense to me, just a few questions/comments. Generally it feels like the attribute extraction gets quite difficult to read, not sure if we can really improve this though (maybe splitting some types into pre/post v1 but not sure if that actually helps)

[RulaKhaled]

Makes sense to me, just a few questions/comments. Generally it feels like the attribute extraction gets quite difficult to read, not sure if we can really improve this though (maybe splitting some types into pre/post v1 but not sure if that actually helps)

We usually try to keep things as general as possible, so splitting would create a lot of unnecessary work. Type changes typically only happen with major releases. I’ve moved everything to /types to make it easier to read, and hopefully this is as simple as it can be

[nicohrubec]

Thanks for addressing the comments, LGTM