MoonshotAI / MoonshotAI/kimi-code
OAuth 取 token 的重试预算太短且只覆盖 refresh,长任务遇瞬时故障直接断
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 7.5k
- Forks
- 1.2k
- Avg merge
- 11h 53m
- Merged PRs (30d)
- 350
Description
问题
跑长任务时,如果 OAuth 主机短暂不可达(网络抖动、DNS 抽风),取 token 会失败、任务等于断了。现有的重试覆盖对常见的瞬时故障来说太薄。
相关报错(同 #2786):
[internal] OAuth request to https://auth.kimi.com/api/oauth/token failed:
fetch failed: Connect Timeout Error (attempted address: auth.kimi.com:443,
timeout: 10000ms)
#2786 已经让这类失败被正确归类成可重试的 provider.connection_error(不再塌成 [internal]),但底层的重试预算本身仍然太短——这是本 issue 要解决的。
证据
三个点叠加:
-
那个 10s 是 undici 的 connect timeout,不是 OAuth 层的超时。
postForm设了AbortSignal.timeout(30_000)(packages/oauth/src/oauth.ts:57,68),但它只在连接建立之后才开始计时。当 TCP/TLS 根本连不上时,undici 自带的 connect timeout(默认 10s)先触发,而 OAuth 层没法配置它。 -
重试预算小且写死。 只有
refreshAccessToken(packages/oauth/src/oauth.ts:226)对传输层错误重试:maxRetries ?? 3,退避2^attempt * 1000(1s、2s)。放弃前的最坏耗时 ≈10s + 1s + 10s + 2s + 10s≈ 33s。长任务里,auth 主机不可达超过 ~30s,这一轮就彻底失败。 -
覆盖不全。
requestDeviceAuthorization(oauth.ts:119)和pollDeviceToken(oauth.ts:168)直接调postForm,完全没有重试。登录流程对传输层故障零容错。
refresh 最终失败后,上层把它当可重试连接错误处理(v1 agent-core 里是 retryable: true + GOAL_PROVIDER_CONNECTION_PAUSE,见 agent-core/src/errors/codes.ts:333、agent-core/src/agent/turn/index.ts:1468),停下等恢复,而不是自动续命——所以任务一直停着,等网络恢复并 resume。
期望
希望长任务遇到短暂网络问题能自动撑过去而不是直接断;登录流程对网络抖动也更能扛一点。具体重试几次、超时多少是你们的工程取舍,我就不瞎给数值了。
关联
- #2786 / PR #2788:让这类失败被正确归类为可重试错误(修了分类,没修预算)。
- #2787:把 OAuth 错误分类下沉到 oauth 包去重。如果本 issue 改变了 refresh 失败时抛出的错误形状(比如新增"重试耗尽"错误类),建议先做 #2787 再做本 issue,这样分派表只改一处。
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in packages/oauth/src/oauth.ts at postForm and the requestDeviceAuthorization, pollDeviceToken, and refreshAccessToken entry points. Read the referenced agent-core error handling and #2787 before deciding how retry exhaustion should be represented. Done means transient OAuth transport failures receive an appropriate retry budget across the login and refresh flows, with tests covering the behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- authentication, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100