Moe Hamade 309df1ab61 fix: evaluate the rate-limit gate against the route each request takes ...

Addresses review on #812. Both findings are the same mistake: the route
was sampled at a moment that need not match the request it governs.

The gate was checked once, before a route wait that can last a minute.
Start with Tor selected, disable it during the wait, and the request
goes direct having consulted only the Tor deadline -- contacting a
direct IP whose own cooldown is still running. The gate is now
re-evaluated after the wait, when the route the request will take is
finally known.

The cooldown was likewise recorded against the mode selected when the
response arrived, not the one the call was made on. Changing the setting
mid-flight filed it in the wrong bucket, freeing the limited route and
suppressing the newly selected one. The route is now sampled
immediately before each attempt and reused for that attempt's response
and its retry decision.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-02 15:56:25 +03:00

..

src

fix: evaluate the rate-limit gate against the route each request takes

2026-08-02 15:56:25 +03:00

build.gradle.kts

fix: lock wear dependencies in CI

2026-07-29 12:20:48 +02:00

gradle.lockfile

fix: restore Android Studio sync with strict Gradle security

2026-07-29 18:15:50 +02:00

lint-baseline.xml

bump targetSdk (#526)

2025-12-14 21:55:41 +07:00

proguard-rules.pro

persist

2026-07-29 03:41:16 +02:00