feat(core): Instrument LangGraph StateGraph #18110
Conversation
size-limit report 📦
|
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.
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| [SEMANTIC_ATTRIBUTE_SENTRY_ORIGIN]: LANGGRAPH_ORIGIN, | ||
| [GEN_AI_OPERATION_NAME_ATTRIBUTE]: 'create_agent', | ||
| }, | ||
| }, |
There was a problem hiding this comment.
Bug: Missing SEMANTIC_OP Attribute in Span Creation (Bugbot Rules)
Missing SEMANTIC_ATTRIBUTE_SENTRY_OP in span attributes. According to SDK conventions, when calling startSpan API, both SEMANTIC_ATTRIBUTE_SENTRY_ORIGIN and SEMANTIC_ATTRIBUTE_SENTRY_OP must be set in the attributes object. While the 'op' field is set on the span options, the SEMANTIC_ATTRIBUTE_SENTRY_OP attribute is not included in the attributes object. This should be [SEMANTIC_ATTRIBUTE_SENTRY_OP]: 'gen_ai.create_agent' in the attributes.
| [SEMANTIC_ATTRIBUTE_SENTRY_ORIGIN]: LANGGRAPH_ORIGIN, | ||
| [GEN_AI_OPERATION_NAME_ATTRIBUTE]: 'invoke_agent', | ||
| }, | ||
| }, |
There was a problem hiding this comment.
Bug: Missing SEMANTIC_ATTRIBUTE_SENTRY_OP in Span Attributes (Bugbot Rules)
Missing SEMANTIC_ATTRIBUTE_SENTRY_OP in span attributes. According to SDK conventions, when calling startSpan API, both SEMANTIC_ATTRIBUTE_SENTRY_ORIGIN and SEMANTIC_ATTRIBUTE_SENTRY_OP must be set in the attributes object. While the 'op' field is set on the span options, the SEMANTIC_ATTRIBUTE_SENTRY_OP attribute is not included in the attributes object. This should be [SEMANTIC_ATTRIBUTE_SENTRY_OP]: 'gen_ai.invoke_agent' in the attributes.
| instrumentLangGraph(options); | ||
| }, | ||
| }; | ||
| }) satisfies IntegrationFn; |
There was a problem hiding this comment.
Bug: Inconsistent Options Handling in LangGraph Integration (Bugbot Rules)
The integration object returned by _langgraphIntegration includes an options property, but LangChain integration (the equivalent pattern this is based on) does not include it. According to the codebase pattern, when using generateInstrumentOnce, the integration should NOT store options in the returned object since the options are passed directly to instrumentLangGraph(options) in the setupOnce method. The options property in the returned object is only used for integrations that don't use generateInstrumentOnce. This inconsistency could cause issues with integration setup and option handling. The options, line on line 14 should be removed to match the LangChain pattern.
| return result; | ||
| }, | ||
| ); | ||
| }, |
There was a problem hiding this comment.
Bug: Uncaught Errors in startSpan Invocation Handling (Bugbot Rules)
Missing error handling in startSpan call for instrumentCompiledGraphInvoke. According to review rules, when calling startSpan, error cases should be handled with try/catch and captureException. The async callback (line 95) can throw errors from Reflect.apply (line 121) but these are not caught. Similar integrations (e.g., OpenAI) wrap the original method call in try/catch and call captureException with appropriate mechanism details. This should wrap lines 121 in a try/catch block and call captureException with mechanism type 'auto.ai.langgraph.invoke' on errors.
|
|
||
| return compiledGraph; | ||
| }, | ||
| ); |
There was a problem hiding this comment.
Bug: Unhandled errors in startSpan: wrap and report with captureException (Bugbot Rules)
Missing error handling in startSpan call for instrumentStateGraphCompile. According to review rules, when calling startSpan, error cases should be handled with try/catch and captureException. The callback (line 44) can throw errors from Reflect.apply (line 45) but these are not caught. Similar integrations (e.g., OpenAI) wrap the original method call in try/catch and call captureException with appropriate mechanism details. This should wrap line 45 in a try/catch block and call captureException with mechanism type 'auto.ai.langgraph.compile' on errors.
|
|
||
| if (inputMessages && recordInputs) { | ||
| const truncatedMessages = truncateGenAiMessages(inputMessages); | ||
| span.setAttribute(GEN_AI_REQUEST_MESSAGES_ATTRIBUTE, JSON.stringify(truncatedMessages)); |
There was a problem hiding this comment.
Bug: Normalize LangChain messages before truncation bug
The code passes raw LangChainMessage objects directly to truncateGenAiMessages without first normalizing them. The truncateGenAiMessages function expects messages in specific formats (with content: string or parts array), but LangChainMessage objects can have various structures (with _getType(), constructor names, serialized format, etc.). This should normalize messages first using normalizeLangChainMessages before truncating, similar to how the LangChain integration handles it in utils/langchain/utils.ts line 283. The correct approach would be:
const normalizedMessages = normalizeLangChainMessages(inputMessages);
const truncatedMessages = truncateGenAiMessages(normalizedMessages);
RulaKhaled
force-pushed
the
instrument-langgrapgh
branch
from
6b9a670 to
e45920a
Compare
This PR adds official support for instrumenting LangGraph StateGraph operations in Node with Sentry tracing, following OpenTelemetry semantic conventions for Generative AI.
Currently supported:
Node.js - Both agent creation and invocation are instrumented in this PR
ESM and CJS - Both module systems are supported
The langgraphIntegration() accepts the following options:
e.g
Operations traced: