#17228 fixed the stale-context_token case where iLink returns ret=-2 with errmsg="unknown error". In the wild I'm hitting a closely related variant that the current check misses: ret=-2 with errmsg=None (empty). The adapter falls through to the rate-limit branch and burns all retries against the dead token, same net symptom as the original bug. ERROR gateway.platforms.weixin: [Weixin] send failed to=o9cq80_r: iLink sendmessage rate limited: ret=-2 errcode=None errmsg=None ERROR gateway.platforms.base: [Weixin] Fallback send also failed: iLink sendmessage rate limited: ret=-2 errcode=None errmsg=None Same recovery pattern as #17228: after a user-initiated inbound message refreshed the session, the next cron push went through immediately with no code change. So this is a session-expired signal, not a frequency limit — iLink is just returning an empty errmsg instead of the string "unknown error". """True when iLink returns ret=-2 / errcode=-2 with 'unknown error', return (errmsg or "").lower() == "unknown error" (errmsg or "").lower() == "unknown error" returns False when errmsg is None or "", so the tokenless-retry branch never fires for the empty-errmsg variant. Treat both "unknown error" and empty/None errmsg as stale-session signals. A genuine rate limit from iLink carries a populated errmsg ("frequency limit" / "too frequently" / similar), so we don't mask real throttling — and even if a rate limit did slip through, the worst case is one extra tokenless attempt before the normal rate-limit backoff kicks in.

• stale session: ret=-2, errmsg="unknown error" OR errmsg empty/None Treating "unknown error" and empty/None errmsg as stale-session signals return msg == "unknown error" I've applied this patch locally and the cron-initiated pushes recover on the first retry instead of dropping — same behaviour the #17228 fix produces for the "unknown error" variant. Happy to send this as a PR (with a regression test covering errmsg=None / "" / "unknown error" / "frequency limit"). Want me to open one, or would you prefer to fold it into the existing helper yourself? I don't want to step on an in-flight branch.

TL;DR

Update the _is_stale_session_ret function to treat both "unknown error" and empty/None errmsg as stale-session signals.

Guidance

• Review the proposed fix in the issue, which widens the condition to check for empty/None errmsg in addition to "unknown error".
• Verify that the updated function behaves correctly for different errmsg values, including None, "", "unknown error", and "frequency limit".
• Consider adding regression tests to cover these scenarios.
• Before opening a PR, check if there are any in-flight branches that may conflict with this change.

Example

def _is_stale_session_ret(
    ret: "Optional[int]", errcode: "Optional[int]", errmsg: "Optional[str]",
) -> bool:
    # ...
    msg = (errmsg or "").strip().lower()
    if not msg:
        return True
    return msg == "unknown error"

Notes

The fix assumes that a genuine rate limit from iLink always carries a populated errmsg. If this assumption is incorrect, the updated function may mask real throttling.

Recommendation

Apply the proposed workaround by updating the _is_stale_session_ret function as described, and add regression tests to ensure the function behaves correctly in different scenarios.