Repository navigation
fix(baidu_netdisk): probe once when the rate-limit pause ends - #3255
Open
zeroornull wants to merge 2 commits into
Open
zeroornull wants to merge 2 commits into
zeroornull wants to merge 2 commits into
Conversation
… deletes Baidu answers bursts of filemanager calls with errno 12 whose info[] item carries 31034 (frequency control). The driver only looked at the outer errno, retried 3 times within ~5s while the window lasts ~16s, and the S3 gateway discarded fs.Remove's error, so DeleteObject always returned 204 and kopia never retried: objects were silently left behind. baidu_netdisk: - parse info[].errno of failed batches; 31034 (outer or per item) is a rate limit and unwraps to errs.TemporaryCapacity - shared per-instance cooldown: on 31034 all requests pause (8s, doubling on consecutive windows, capped at 30s, small jitter, reset after a success); hits inside an open window do not extend it; no limiter otherwise - per-call cooldown wait budget (35s), then the rate-limit error is returned - requests honour ctx; manage() takes ctx - delete of a missing path (-9 / 31066) is success and not retried s3: - DeleteObject returns Remove errors; rate limits map to 503 SlowDown so clients back off and retry, other errors to 500; missing keys stay 204 - DeleteMulti reports SlowDown per key instead of always InternalError
When the cooldown expired every waiting request fired at once; if Baidu was still throttling they all got 31034 again and the pause escalated. Turn the cooldown into a half-open circuit breaker: - the first 31034 opens it (8s, doubling to 30s, jitter); 31034 from requests sent before it opened is ignored - when the pause ends exactly one request goes out as a probe, the others keep waiting - probe gets 31034: pause again (escalated) and probe at the next expiry - probe gets any other Baidu answer: close the breaker, release everyone - probe fails without an answer (network error, ctx cancelled): hand the probe slot to the next waiter - waiting honours ctx and the per-call 35s budget, after which the call fails with the rate-limit error (S3 503 SlowDown)
cursor
Bot
force-pushed
the
fix/baidu-ratelimit-cooldown-clean
branch
from
October 24, 2026 10:41
18d17e3 to
503dde9
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #3254
Separate from #3208 (List visibility). Do not merge the branches.
Summary / 摘要
When Baidu returns
errno31034 (frequency control), the driver pauses. Previously, when that pause expired every waiting request fired at once; if Baidu was still throttling they all got 31034 again and the pause escalated. This PR turns the cooldown into a half-open circuit breaker so only one probe goes out at expiry.百度返回
errno31034（频控）时驱动会暂停。原先暂停结束后，所有等待中的请求会一起发出；若百度仍在限流，它们会再次全部收到 31034，暂停时间被反复拉长。本 PR 把 cooldown 改成半开熔断：到期时只放行一个 probe。Behavior / 行为：
首次 31034 打开熔断（基准 8s，翻倍到 30s，带抖动）；熔断打开前已发出的请求再收到 31034 会被忽略。
暂停结束时只放行一个 probe，其余继续等待。
probe 仍是 31034：再次暂停（加长）并在下次到期再 probe。
probe 得到其它百度响应：关闭熔断，放行所有等待者。
probe 没有结论（网络错误、ctx 取消）：把 probe 名额交给下一个等待者。
ctxand a per-call 35s budget; after that the call fails with the rate-limit error (S3 maps to 503 SlowDown).等待尊重
ctx与单次调用 35s 预算；超时后以限流错误失败（S3 映射为 503 SlowDown）。Files / 文件：
drivers/baidu_netdisk/ratelimit.godrivers/baidu_netdisk/ratelimit_test.godrivers/baidu_netdisk/util.goThis is separate from #3208 (pending List visibility). Do not merge the branches.
与 #3208（写后 List 可见性）无关，不要合并分支。
Testing / 测试
drivers/baidu_netdisk/ratelimit_test.go(breaker open / probe success / probe still 31034 / probe handoff / wait budget).openlist-ratelimit-live-result-20261021112251.json).deploy/ratelimit-plus-debug/3d383e45, through 2026-10-24 daily backups):kine-percona-backupon 2026-10-24 03:00 CST: completed successfully;complete.jsonHeadObject verified through OpenList→Baidu (this was the prior 404 failure mode).daily-full-clean-20261023190013(started 2026-10-23 19:00 UTC = 2026-10-24 03:00 CST): PartiallyFailed with 1 error; failure is alertmanager PVB readiness timeout (context deadline exceeded), not Baidu rate-limit. 109/110 PodVolumeBackups Completed.SlowDown/RateLimitedstrings left in access logs for the quiet current window; currentlog.loghas 0×31034). errno 600 on list retried and succeeded.fix/baidu-ratelimit-cooldown-clean, tip129ab900) with no debug logging and without fix(op): keep written objects visible until a List returns them #3208 commits.AI Disclosure / AI 使用声明