fix(gateway): recognize Weixin's rate-limit wording in the delivery ledger's flood classifier

[nftpoetrist]

Summary

is_flood_error() (gateway/delivery_ledger.py) only recognized Telegram's two flood shapes: the
adapters' fail-closed flood_control:<seconds> prefix, and python-telegram-bot's raw "Flood control exceeded... Retry in N seconds" text. This function gates whether a final-send failure gets a timed
redelivery armed (_schedule_flood_redelivery) and whether the boot/runtime sweeps
(sweep_recoverable, sweep_failed_for_runtime) treat a failed row as still inside its penalty window
(adopt without spending an attempt, wait for the deadline) or as an ordinary failure (claim and resend
immediately).

Weixin's rate-limit circuit breaker fails a send closed with neither shape —
"iLink sendmessage rate limited; cooldown active for {N}s" (gateway/platforms/weixin.py, a bare
SendResult(success=False, error=str(exc)), no retry_after/flood_control: framing) — so a Weixin
send throttled by iLink never got a flood timer armed. The row sat as an ordinary failed row, and the
next boot sweep or reconnect-triggered sweep claimed and resent it immediately, spending a redelivery
attempt inside the still-active cooldown instead of waiting it out — defeating the point of the
flood-ledger mechanism for this one platform.

Fix

Widened is_flood_error() to also recognize the platform-neutral rate-limit classification already
used by _send_with_retry's in-attempt backoff — classify_send_error() in
gateway/platforms/base.py (imported locally inside the new _classified_rate_limited() helper, best-
effort, to avoid a module-load-order dependency between delivery_ledger.py and the much larger
gateway/platforms/base.py) — rather than hand-rolling a second, Weixin-specific regex. This is the
same chokepoint _is_rate_limited_error() already wraps for the in-attempt backoff decision, so any
future adapter whose error text matches "flood"/"too many requests"/"retry after"/"rate limit" gets the
ledger's timed-redelivery treatment too, not just Weixin.

Also extended the wait-seconds extraction (_raw_flood_wait, used by flood_wait_seconds /
flood_not_before) with a second regex, _COOLDOWN_WAIT_RE, matching Weixin's own embedded
"cooldown active for Ns" figure — so the redelivery timer honors the platform's actual cooldown
instead of falling back to the generic 60s default every time.

_COOLDOWN_WAIT_RE = re.compile(r"cooldown active for\s+(\d+(?:\.\d+)?)s", re.IGNORECASE)

Why this approach over a scoped Weixin-only pattern

Reusing classify_send_error() was judged safer and more maintainable than adding a narrow
Weixin-specific literal match:

• It's the same classification the send-retry path already trusts for "is this transient/rate-limited," so the ledger and the in-attempt backoff can't drift out of sync on what counts as a flood.
• It automatically covers any other adapter whose error text says "rate limit"/"too many requests"/"retry after" without a dedicated flood_control: prefix, closing the same class of gap ahead of time rather than one platform at a time.
• Verified no regression risk: _RETRYABLE_ERROR_PATTERNS (the separate "transient"/network-error bucket) doesn't overlap with the rate_limited classifier's patterns, and is_flood_error() is only ever called on the row's last_error string — never on "send_path_degraded" or blocked/forbidden/not-found texts, which the classifier correctly leaves unmatched (covered by a new regression assertion).

Testing

Extended tests/gateway/test_delivery_flood_invariants.py (the current, focused successor to the
older/larger flood-retry test file) with four new tests:

• test_weixin_rate_limit_text_classifies_as_flood_and_extracts_its_own_wait — unit-level: is_flood_error() recognizes the Weixin text, flood_wait_seconds() reads the embedded 12.3 figure (not the generic default), and an ordinary (non-rate-limited) Weixin failure is correctly left unmatched.
• test_weixin_rate_limit_arms_timed_redelivery_not_immediate_retry — end-to-end through sweep_failed_for_runtime: a Weixin flood row is not claimed while still inside its cooldown, and is claimed (with the rate-limit marker) once the deadline passes.
• test_weixin_rate_limit_boot_adoption_does_not_spend_attempt — end-to-end through sweep_recoverable + sweep_failed_for_runtime: a dead-owner Weixin flood row is adopted without spending an attempt while cooling down, then claimed normally past the deadline (mirrors the existing Telegram boot-adoption test).
• test_telegram_flood_detection_unaffected_by_broader_classifier — confirms Telegram's two established shapes and the "permanent rejection is not a flood" invariant are unchanged.

Ran: tests/gateway/test_delivery_flood_invariants.py, test_delivery_ledger.py, test_delivery.py,
test_weixin.py, test_restart_redelivery_dedup.py, test_send_error_classification.py — 109 passed.
ruff check on both changed files: clean.

Mutation-verified: reverted gateway/delivery_ledger.py via patch file (tests kept), reran the
four new tests — 3 of 4 failed as expected (AssertionErrors on the exact behaviors the fix adds); the
Telegram-only invariant test correctly still passed since it doesn't exercise the new code path.
Reapplied the fix — all 6 tests in the file pass again.

Competitor check

Fresh search across weixin flood / is_flood_error / delivery_ledger weixin / weixin rate limit /
flood_control weixin / delivery ledger rate limit / flood-capped / delivery_ledger, all states,
right before pushing:

• fix: avoid fallback sends during Weixin cooldown #58256 ("avoid fallback sends during Weixin cooldown", open since 2026-07-04) — read the actual diff. It touches gateway/platforms/base.py's _send_with_retry (in-attempt fallback/notice avoidance) and gateway/platforms/weixin.py's send() (adds error_kind/retry_after to SendResult, via a _retry_after_from_error extractor using the same cooldown active for Ns wording). It does not touch gateway/delivery_ledger.py at all, and its base commit predates current main's _send_with_retry (which already has equivalent, differently-shaped rate-limit handling — likely converged on independently). No overlap with this PR's target file; noted here as complementary, adjacent prior art for the in-attempt/SendResult-enrichment layer, not the post-exhaustion ledger layer this PR fixes.
• fix(weixin): make rate-limited sends observable and recoverable (#94146) #94423 ("make rate-limited sends observable and recoverable ([Bug]: Weixin live replies are silently dropped after rate-limit incidents, even after fresh QR login and on latest main #94146)", open) — also only touches gateway/platforms/weixin.py + its own tests; also does not touch delivery_ledger.py.
• fix(gateway): recover flood-refused replies after the penalty (#104799, salvage #103669) #104950 ("recover flood-refused replies after the penalty (fix(gateway): flood_control send failures are never retried by the delivery ledger's sweeps — final replies stuck as failed until restart #104799, salvage fix(gateway): redeliver a flood-refused final reply once the penalty passes #103669)") — merged today, and already an ancestor of this branch's base. It built the general timed-redelivery machinery this PR extends (the event-woken per-bot-identity worker, pending_flood_retries, the sweep_recoverable/sweep_failed_for_runtime deadline enforcement — all read and relied on above) and validated it end-to-end for Telegram, but its own is_flood_error() stayed Telegram-only; this PR is the direct, non-duplicate follow-up for Weixin.
• fix(delivery-ledger): replay flood_control sends instead of stranding them #103877 ("replay flood_control sends instead of stranding them") — closed 2026-09-05, explicitly described in fix(gateway): recover flood-refused replies after the penalty (#104799, salvage #103669) #104950's body as an inferior/superseded candidate ("bare allowlist does not protect the penalty window or arrange a timed wake"). Not a live competitor.
• No other open or recently-closed PR touches is_flood_error, flood_wait_seconds, or Weixin's rate-limit text in delivery_ledger.py.

[Enough1122]

AI code review — automated review for reference; please use your judgment.

Summary

Teaches the delivery ledger's flood classifier to recognise Weixin's own rate-limit wording (cooldown active for Ns) — both extracting the embedded wait and treating classifier-recognised rate limits as floods for timed redelivery. Well-tested: Weixin timed-redelivery, boot adoption, and Telegram no-regression invariants.

Findings

• Non-blocking — gateway/delivery_ledger.py:59-60: _raw_flood_wait now includes the generic _COOLDOWN_WAIT_RE, so any error text containing "cooldown active for Ns" counts as a flood even when the platform-neutral classifier does not recognise it as rate-limited. Slightly broader than the docstring's stated intent (classifier-gated recognition). In practice the consequence is only a timed delay rather than an immediate retry, so the failure mode is benign.
• Non-blocking — gateway/delivery_ledger.py:38-45: classify_send_error(None, text) passes None where an error/adapter object may be expected. Any misbehavior is swallowed by the try/except → False, which is safe but could silently disable the new recognition if the classifier's signature changes. Consider a debug log in the except branch.

Verification

• tests/gateway/test_delivery_flood_invariants.py:95-155 covers classification, wait extraction, sweep timing, and boot adoption for the Weixin shape, plus Telegram invariance. No security concerns.