Python SDK客户端日志记录导致的死锁问题分析

在modelcontextprotocol/python-sdk项目中，开发人员发现了一个与客户端日志记录相关的死锁问题。这个问题表现为当工具函数中包含客户端日志记录时，Python客户端会陷入挂起状态，无法正常完成执行。

问题现象

当开发者在工具函数中使用ctx.info()进行日志记录时，例如以下代码片段：

@mcp.tool()
async def simple_tool_with_logging(x:float, y:float, ctx:Context) -> str:
    await ctx.info(f"Processing Simple Tool")
    logger.debug("IN SIMPLE_TOOL")
    await ctx.report_progress(1, 2)
    return x*y

这段代码在Claude Desktop和Inspector环境下可以正常工作，但在纯Python客户端环境下会出现执行无法完成的情况。

问题根源

经过深入分析，问题出在session.py文件中的消息处理逻辑。当前实现中，所有通知消息都会被发送到_incoming_message_stream_writer，包括日志消息通知(LoggingMessageNotification)。这导致了消息循环的死锁。

技术细节

在异步通信模型中，客户端和服务器之间通过消息流进行通信。当客户端发送日志消息时，这些消息会被封装为LoggingMessageNotification对象。当前的实现没有对这些特殊类型的消息进行过滤，导致它们被重新发送回消息流，形成了无限循环。

解决方案

临时解决方案可以修改消息发送逻辑，增加对LoggingMessageNotification类型的检查：

if not isinstance(notification.root, LoggingMessageNotification):
    await self._incoming_message_stream_writer.send(notification)

这个修改虽然能解决问题，但并不是最优雅的方案。更完整的解决方案应该包括：

1. 明确区分日志消息和普通通知消息的处理路径
2. 为不同类型的消息建立独立的处理通道
3. 实现更精细化的消息路由机制

影响范围

这个问题主要影响：

• 使用纯Python客户端的开发者
• 在工具函数中使用ctx.info()等日志记录功能的场景
• 需要详细调试信息的开发环境

临时规避方法

在问题完全修复前，开发者可以采取以下临时措施：

1. 避免在工具函数中使用ctx.info()等客户端日志记录
2. 降低日志级别，不输出调试信息
3. 使用标准日志记录器而非客户端特定的日志接口

总结

这个死锁问题揭示了在异步消息处理系统中需要特别注意消息类型的区分和路由。正确的消息分类和处理机制对于系统的稳定运行至关重要。开发团队正在积极修复这个问题，未来版本将提供更健壮的消息处理机制。