Skip to content

Use LangSmith runtime override API instead of monkey-patching aio_to_thread#1477

Open
xumaple wants to merge 1 commit intomainfrom
maplexu/langsmith-runtime-override
Open

Use LangSmith runtime override API instead of monkey-patching aio_to_thread#1477
xumaple wants to merge 1 commit intomainfrom
maplexu/langsmith-runtime-override

Conversation

@xumaple
Copy link
Copy Markdown
Contributor

@xumaple xumaple commented Apr 23, 2026

Summary

  • Replace the process-wide monkey-patch of langsmith._internal._aiter.aio_to_thread with LangSmith's official set_runtime_overrides(aio_to_thread=...) API (added in langsmith 0.7.34)
  • Bump langsmith dependency from >=0.7.0 to >=0.7.34

The monkey-patch was fragile against LangSmith internal refactors. The new API is a supported hook for frameworks with non-standard event loops that don't implement run_in_executor.

@xumaple xumaple force-pushed the maplexu/langsmith-runtime-override branch 2 times, most recently from f9e7ec1 to 76167ff Compare May 6, 2026 16:26
…ing aio_to_thread

LangSmith 0.7.34 added `set_runtime_overrides(aio_to_thread=...)` which
provides a supported hook for frameworks with non-standard event loops.
This replaces the process-wide monkey-patch of `langsmith._internal._aiter.aio_to_thread`
with a call to the official API, making the integration less fragile
against LangSmith internal refactors.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@xumaple xumaple force-pushed the maplexu/langsmith-runtime-override branch from 76167ff to acfd0d1 Compare May 6, 2026 17:27
@xumaple xumaple marked this pull request as ready for review May 6, 2026 18:11
@xumaple xumaple requested review from a team as code owners May 6, 2026 18:11
_aio_to_thread_patched = True
Safe to call multiple times; the override is only installed once.
"""
global _aio_to_thread_override_installed # noqa: PLW0603
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any way to avoid a global variable? Could this variable live in the interceptor? I'm guessing probably not since we might want to support multiple instances of the plugin running at the same time?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants