fix(core): Fix deep nesting of runnables within traceables #8853
Conversation
🦋 Changeset detectedLatest commit: ae3acfa The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
| const tracerV2 = callbackManager.handlers.find( | ||
| (handler) => handler.name === "langchain_tracer" | ||
| ) as LangChainTracer; | ||
| tracerV2?.updateFromRunTree(implicitRunTree); |
There was a problem hiding this comment.
Previously this was always setting callbackManager._parentRunId to the implicit traceable value, so runs would get flattened
Before #8849, this only applied in the case where a LangChainTracer was instantiated automatically, which happens if it is not manually passed and environment variables are set. My fix in #8849 for cases where a tracer is passed manually caused this reparenting logic to apply even if the tracer were already present, exposing the issue
This change only applies the reparenting on the initial handoff from LangSmith to LangChain (if there's no already existing parent id on the callback manager and there is an implicit one from a wrapping LangSmith traceable). The reverse handoff is handled in langsmith traceable
| }); | ||
| expect(thirdCallParams).toMatchObject({ | ||
| end_time: expect.any(Number), | ||
| inputs: { |
There was a problem hiding this comment.
Removing inputs in these tests is a side-effect of bumping langsmith - we made an optimization to stop unnecessarily double-sending inputs in the second update call for a run when they were not changing.
3 participants
Previously the callback manager would always prefer the implicit parent ids, which flattened deeply nested runnables within traceables.