LangChain Community Reports Tool Middleware Typing Defect; Custom Context May Be Flagged as Incompatible by Pylance

On October 5, the LangChain community added an issue report saying that when @wrap_tool_call is combined with a custom context_schema, Pylance may infer the middleware’s context type as None and consequently flag it as incompatible with the type required by the agent. The reported environment includes LangChain 1.4.3, langchain-core 1.6.6, and Windows, along with a minimal example. At the time of review, the issue remained open and the page listed no related fix. Community report

The example first defines an agent state with a retry field and an AgentContext containing user_id, then uses @wrap_tool_call(state_schema=State) to wrap a function that calls the handler directly. After passing it to create_agent with context_schema=AgentContext, the type checker reports that no overload matches. The error message says that ContextT is invariant, so None cannot be substituted for AgentContext. The author says that using a class explicitly declared as AgentMiddleware[State, AgentContext] passes the check, but the full scope of applicability still needs upstream confirmation. Reproduction and alternative approach

The official API contracts support this explanation of the mechanism: create_agent shares ContextT between context_schema and middleware, and the two must be consistent; the decorator’s public parameters include state_schema but no corresponding context_schema. The tool interception interface can be used to retry, monitor, or modify tool responses, so a type propagation issue can affect developers who encapsulate such logic in reusable middleware. Agent API, Decorator API

For teams using strict type checking, this kind of incompatibility diagnostic may hinder editor checks or continuous integration; this is an engineering impact inferred from the case. The report does not show an actual tool execution failure or establish that user identification data disappears at runtime. Engineers can first verify the class-based approach with their own versions, and check type diagnostics and runtime results separately. Follow-up should track whether upstream completes generic type propagation for the decorator and validates both synchronous and asynchronous tool interception paths.