 what
|
ee5e5b96af
|
feat: 添加 WithStreamErrors 查询流式调用执行过程中的异常
流式输出/双向流的 handler（Python 生成器）如果执行过程中抛异常，
Invoke[chan T] 本身的 err 只描述"调用有没有发起成功"，跟这个异常
无关（永远是 nil），channel 只会静默提前关闭，调用方原本完全无法
感知。新增 WithStreamErrors(ctx) 返回一个包过的 ctx 和一个查询函数
streamErr，opt-in 之后可以查到具体错误。
错误记录挂在 WithStreamErrors 返回的 ctx 的对象图里（context.WithValue），
不是全局表——调用方不再引用 ctx/channel 时会被 GC 自然回收，不需要
任何显式清理逻辑，也不依赖 ctx.Done()，即使用 context.Background()
也能正常释放；ctx 之后被别的 context.With*（包括 StickyCtx）再包一层
也不影响查询。
同时补充完整的自动化测试覆盖 example/main.go 里演示过的所有功能：
四种调用模式 × int/struct/slice/[]byte 的组合（client_test.go）、
WithHandlers/call_go 全双工（handlers_test.go）、NewSession 隔离性
与 StickyCtx 路由（session_test.go），之前这些只能靠人肉跑 go run
看输出，现在都有真实断言。
|
2026-07-23 16:24:05 +08:00 |
|
|
what
|
6ccec66a1e
|
fix: WithDefaultTimeout 不再套用到流式输出/双向流
流式输出（Invoke[chan T]）返回的 channel 由调用方通过 range 自行决定
消费多久，典型场景是流式聊天回复，可能正常持续几十秒甚至更久。之前
WithDefaultTimeout 会不分场景地把这个全局默认超时套到整个调用生命周期
上（包括流还在正常输出的过程中），导致长时间运行的正常流式响应被腰斩。
改成流式输出/双向流完全不受 WithDefaultTimeout 影响，只认调用方显式传入
的 ctx deadline；需要超时保护的话必须自己 context.WithTimeout。普通调用
和流式输入不受影响，继续吃池子的默认超时。
新增 TestStreamOutIgnoresDefaultTimeout 验证；example/main.go 的
demoTimeout 补充示例4 演示这一行为；README 同步更新。
|
2026-07-23 14:24:10 +08:00 |
|
|
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 |
|