 what
|
4f74627be1
|
fix: 修复流式输入 ctx 取消时 handler 线程永久阻塞泄漏的问题
流式输入模式下，handler 线程阻塞在 _ChunkIter.__next__ → chunk_q.get()
等待下一个输入块时，如果 ctx 取消导致 Go 关闭连接，_ConnMux._reader
原来只往 call_q 推了 None、给 _active_tids 里的线程注入 InterruptedError，
没有处理 chunk_q。而 PyThreadState_SetAsyncExc 打断不了阻塞在
queue.Queue.get()（无 timeout）上的线程，因为它是纯 C 层等待、不会回到
字节码解释循环检查待处理异常，导致这个线程永久卡死、泄漏。
修复：连接关闭时也往 chunk_q 推一个 None 哨兵，_ChunkIter.__next__ 已经
把 None 当作流结束处理，会正常抛 StopIteration 让线程退出。
新增 pool_test.go 里的 TestStreamInputCancelDoesNotLeakThread 复现并验证
修复（通过对比 count_threads() 前后线程数）。python 包版本号同步升到 0.1.5。
|
2026-07-23 14:07:47 +08:00 |
|
|
what
|
eb6ebd8632
|
test: 补充 WithEnv 环境变量注入的测试
验证 WithEnv 设置的变量能真正传进子进程，避免上层配置解析漏掉该
字段时无法被发现（此前 framework-v2 里 env 字段一直未接入，线上因
此从未真正生效过）。
|
2026-07-23 13:48:34 +08:00 |
|
|
what
|
983d106166
|
fix: 修复流式 handler 中途抛异常时 end/error 消息错位的问题
_dispatch 处理生成器（yield）handler 时之前用 try/finally 包裹迭代，
导致中途抛异常时会先发一条 end、再发一条 error。Go 侧 invokeStreamOut
读到第一条终止消息（end）就直接返回并把连接标记健康放回池子，遗留的
error 消息留在 socket 里，会被下一个复用该连接的调用错误地当成自己的
响应读走，造成两次完全不相关的调用结果串号。
改成不用 finally，只在生成器正常耗尽后发送一次 end；异常直接交给外层
统一处理发送 error，保证一次调用只产生一条终止消息。
新增 pool_test.go 里的 TestStreamErrorMidwayCorruptsNextCall 复现并验证修复。
|
2026-07-23 13:44:45 +08:00 |
|
|
what
|
0f4a4ded53
|
feat: 添加 WithDefaultTimeout 默认超时配置
Invoke 之前完全依赖调用方传入的 ctx 控制超时，池子被占满或 Python 侧
handler 阻塞时，未设置 deadline 的调用会永久阻塞且不报错。新增
WithDefaultTimeout 选项，仅在 ctx 未设置 deadline 时兜底生效，调用方
显式设置的超时优先级更高。
同时补充 example 中的阻塞/超时演示（demoTimeout、demoBlocking）和
pool_test.go 集成测试，覆盖池占满排队、默认超时、显式 deadline 优先级、
流式输出超时后 channel 静默关闭等场景。
|
2026-07-23 10:37:24 +08:00 |
|