fix(octopus): don't re-read a rate-limited GraphQL response

[springfall2008]

Problem

When Octopus rate-limits a GraphQL request (KT-CT-1199), async_read_response() sleeps for 5 seconds and returns None. async_read_response_retry() then treated that None as worth retrying, and re-read the same response four more times, with a 1, 2, 4 and 8 second backoff.

aiohttp caches the response body, so every re-read returns the same rate limit. The existing 401/403 handling in that loop already says so. As a result, one request to Octopus logged five warnings and held the component for about 35 seconds, before failing anyway.

Seen live on a flexPlannedDispatches poll: five Rate limit error in request warnings 6, 7, 9 and 13 seconds apart (5 s plus the backoff), followed by get-intelligent-dispatches (status 200): None.

Change

A rate limit is now definitive for the response, as 401/403 already are:

• async_read_response() records the rate limit in last_read_rate_limited, and no longer sleeps.
• async_read_response_retry() returns straight away when that flag is set.

Every other failure retries exactly as before.

Tests

test_octopus_read_response_retry Test 7 asserted the old retry. It mocked a second read succeeding, which can't happen on a cached body. It now drives a real rate-limit body through the real reader, and checks:

• the body is read once;
• nothing sleeps;
• exactly one warning is logged;
• the result is None, and failures_total goes up by 1.

It failed before the fix, with the response read 5 times. All 24 Octopus test modules pass, and so do ./run_all --quick and pre-commit.

Not in this PR

Deliberately scoped to the retry loop. Two related gaps, left as possible follow-ups:

• No backoff across polls: the dispatch poll runs again 2 minutes later, whatever happened.
• A failed dispatch fetch publishes an empty planned_dispatches list for that poll. The settings query next to it carries its last known values forward, but the dispatch query doesn't.

🤖 Generated with Claude Code