Rate-limit retry replays a consumed request body for POST/PUT/PATCH
維護者通常 1 天內回覆
評估
- 難度
- 3/5
- 預估耗時
- 1-2 天
- 新手友好度
- 70/100
- Issue 類型
- 缺陷
- 描述清晰度
- 描述清楚
- 活躍度
- 活躍
- 技術堆疊
- go
研究方向
Start with the retry branch in github/github.go at lines 1521–1529, then read NewRequest and the existing retry tests in github/github_test.go named in the issue. Add regression coverage for POST, PUT, and PATCH bodies and for a non-replayable body. Done means retry requests preserve replayable bodies and requests without a replayable body are not retried.
由索引模型根據 Issue 內容生成。
描述
Summary
The automatic primary rate-limit retry path in Client.bareDo re-sends a cloned *http.Request without restoring its body. For any request that carries a body (POST, PUT, PATCH), the original req.Body has already been consumed by the first caller.Do(req) call, so the retry sends an empty body or fails on ContentLength.
Location
github/github.go:1521-1529 (retry branch in bareDo), with request construction at github/github.go:993-1037 (NewRequest) and the send at github/github.go:1464 (caller.Do(req)).
var rateLimitError *RateLimitError
if errors.As(err, &rateLimitError) &&
ctx.Value(SleepUntilPrimaryRateLimitResetWhenRateLimited) != nil {
if err := sleepUntilResetWithBuffer(ctx, rateLimitError.Rate.Reset.Time); err != nil {
return response, err
}
// retry the request now the rate limit should have been reset
newReq := req.Clone(context.WithValue(ctx, SleepUntilPrimaryRateLimitResetWhenRateLimited, nil))
return c.bareDo(caller, newReq)
}
Details
NewRequest encodes the body into a *bytes.Buffer:
var buf io.ReadWriter
if body != nil {
buf = &bytes.Buffer{}
enc := json.NewEncoder(buf)
enc.SetEscapeHTML(false)
err := enc.Encode(body)
if err != nil {
return nil, err
}
}
req, err := http.NewRequestWithContext(ctx, method, u.String(), buf)
For the *bytes.Buffer case, net/http.NewRequestWithContext populates req.GetBody and sets req.ContentLength. However, bareDo never uses GetBody. It calls caller.Do(req) at line 1464, which reads req.Body to EOF (and closes it). When a *RateLimitError triggers the retry branch, req.Clone(...) performs a shallow copy: the cloned request keeps the same consumed *http.Request.Body reader and the original ContentLength. The retry therefore either sends a zero-length body while still advertising the original ContentLength, or returns an error such as http: ContentLength=N with Body length 0.
The fix belongs in this retry path (or in bareDo before every send): call req.GetBody() and assign the resulting reader to req.Body before re-sending. If GetBody is nil (a body that cannot be replayed, for example a stream passed to NewFormRequest), the retry must not be attempted, because there is no way to reconstruct the payload.
Impact
- Users who opt into
SleepUntilPrimaryRateLimitResetWhenRateLimitedand then perform a write operation (POST/PUT/PATCH) can have that write silently truncated to an empty body after a primary rate-limit retry. This is a correctness issue and can cause confusing API errors or, depending on the endpoint, unintended empty updates. - The retry can also fail outright with a
ContentLengthmismatch error instead of succeeding on the second attempt. - GET requests are unaffected, which is why existing tests do not detect this.
Suggested fix
In the retry branch, restore the body from GetBody before cloning or re-sending:
newReq := req.Clone(context.WithValue(ctx, SleepUntilPrimaryRateLimitResetWhenRateLimited, nil))
if req.GetBody != nil {
body, err := req.GetBody()
if err != nil {
return response, err
}
newReq.Body = body
} else if req.Body != nil && req.Body != http.NoBody {
// Body cannot be replayed; do not retry.
return response, err
}
return c.bareDo(caller, newReq)
Applying the restore inside bareDo before each caller.Do would also protect other re-send paths, but the minimal change is the rate-limit retry branch.
Verification
- Static review of
github/github.goat HEAD2190e6a(2026-10-22):NewRequestencodes intobytes.Buffer,bareDocallscaller.Doonce and thenreq.Cloneon retry, and noGetBodyrestoration exists ingithub/github.go. - Existing retry coverage is GET-only. The
SleepUntilPrimaryRateLimitResetWhenRateLimitedtests ingithub/github_test.go(lines 3033, 3066, 3095, 3150, 3201) all construct requests with"GET"andnilbody, so they never exercise body replay. - Suggested regression tests: a table test using POST, PUT, and PATCH where the handler returns a
*RateLimitError(403 with rate-limit headers) on the first call and200on the second, asserting the second request receives the original JSON body. Add a case for a non-replayable body to assert the retry is skipped. - This report is based on static source review. No runtime proof of concept was executed.
- 主要語言
- Go
- 星號
- 11.3k
- 分支
- 2.6k
- 平均合併
- 2 天 8 小時
- 30 天內合併 PR
- 38
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
google/go-github 的其他 Issue
-
otel: redact sensitive query parameters before recording http.url可能已有人在做 @sai5880 於 1 天前認領。 未關閉
難度 4/5 1-2 天 新手友好度 55/100
維護者通常 1 天內回覆
-
Error() methods modify the request URL of the response they wrap可能已有人在做 @AdamMagued 於 2 天前認領。 未關閉
難度 2/5 1-3 小時 新手友好度 30/100
維護者通常 1 天內回覆
-
難度 5/5 一週以上 新手友好度 5/100
google/go-github#4636 · 11 則留言 · 3 個 reaction ·
維護者通常 1 天內回覆
-
http.Client.Timeout is ignored by redirect-aware requests可能已有人在做 @sb123sb123 於 31 天前認領。 未關閉
難度 3/5 1-2 天 新手友好度 68/100
維護者通常 1 天內回覆
-
Add Copilot content exclusion set/get enterprise and org set endpoints可能已有人在做 @Tens1des 於 45 天前認領。 未關閉
google/go-github#4526 · 1 則留言 · 1 個 reaction · 已指派 1 人 ·
維護者通常 1 天內回覆
相似的 Issue
-
bug raised-by:verifier
難度 2/5 1-3 小時 新手友好度 76/100
medici-finance/assay#4177 ·
維護者通常 1 天內回覆
-
bug: admin user creation silently ignores role可能已有人在做 @bfs2021 今天認領。 未關閉bug
難度 2/5 1-3 小時 新手友好度 76/100
eugenioenko/autentico#553 ·
維護者通常 1 天內回覆
-
sidecar: --moriio-parallel-dispatch omits remote_request_id, so a vLLM NixlPushConnector decode dies with KeyError可能已有人在做 @xintin 今天認領。 未關閉kind/bug needs-triage
難度 2/5 1-3 小時 新手友好度 78/100
llm-d/llm-d-router#3607 ·
維護者通常 1 天內回覆
-
automation models
難度 1/5 1-3 小時 新手友好度 74/100
維護者通常 1 天內回覆
-
難度 1/5 1 小時以內 新手友好度 91/100
維護者通常 1 天內回覆