响应式更新
交互式调用方不应只能在等待整个 Flow 结束和轮询状态之间二选一。响应式更新会在调用方真正需要的边界返回，同时由 Flow 继续负责 durable 工作。如果是 Flow 自己在等待外部系统，请使用 Polling。
有意识地选择这个边界：
- 等待 Step 完成 会在一个指定 Step 完成后返回。当该 Step 已使结果可供客户端安全读取或使用时采用它。
- 等待 Attribute 匹配 返回当前命中的 Attribute 值。当调用方需要在业务状态变化后刷新时，使用 revision watermark。
- 等待并流式接收更新 会长轮询下一条增量更新，并从 token 继续读取。它适用于进度或持续变化的 feed。
前两种等待观察 durable 状态。它们适合定义客户端可见的边界，而不是代替应用超时或最终 Flow 结果。Stream 承载有序的增量消息；客户端保存最新的 resume token，并在下一次读取时带上它。
选择超时边界
RequestTimeout 是 SDK 调用的总预算，覆盖所有透明 transport reattachment。正值会为每次 attempt 设置本地 transport deadline。总预算到期时，SDK 返回有类型的 request-timeout 错误。之后针对同一条件的调用会从当前状态重新开始等待。
普通 durable wait 应让 RequestTimeout 保持为 0。此时，它会一直等待，直到成功、Flow 关闭或调用方取消。在 HTTP 或 admission 边界，应显式设置应用响应预算。
Server 还会限制单次 transport attempt。这个 cap 完全是内部行为。SDK 会使用同一 logical Request ID 重新附着，因此它不会重置 RequestTimeout。
每个正在等待的调用在等待期间占用 Flow 的一个 wait slot。得到结果、request timeout、cancellation 或调用方断开连接都会释放这个 slot。因此，被放弃的调用不会累积。
Dex Server 会限制单个 Flow 上的并发 wait 数量。server-zd 默认允许 1,000 个，由 limits.maxLongPollWaitersPerFlow 设置。超出上限的 wait 会以 resource-exhausted 错误失败。每个 Flow 的并发调用方数量应低于这个上限。见 server-zd 限制。
InternalHandlerTimeout 已弃用。Dex 会拒绝负值，其他值都会被忽略。不要设置它。
| 设置 | 默认值 | 行为 |
|---|---|---|
| RequestTimeout | 0 | 调用方可见的 SDK 总预算。0 表示等待到成功、Flow 关闭或调用方取消。 |
| 每个 Flow 的并发 wait | 1,000 | Server 上限 limits.maxLongPollWaitersPerFlow。超出上限的 wait 会以 resource-exhausted 错误失败。 |
| Transport attempt cap | Server 管理 | 只触发透明 reattachment，不是应用可见的 timeout。 |