test(e2e): pin that a gateway rate-limit 429 reaches the usage feed - #1070
Merged
Conversation
A 429 reaches a caller two ways: the upstream throttled us, or the
gateway's own rate limit refused the request before any upstream was
contacted. Only the first is an upstream *attempt*. The gateway's own
refusal leaves the failure path with zero attempts, so it is emitted by a
genuinely different branch — `chat.rs`'s `match charge` zero-attempt arm
rather than its per-attempt loop — and nothing covered that branch.
"Show me this member's 429s" (AISIX-Cloud#1389) is the question that
needs both. Reading the emit code makes it easy to conclude the
zero-attempt case produces nothing at all, because the per-attempt loop
is right there and iterates an empty list; the arm that actually emits it
sits below the loop. A test settles that far better than a careful read
does.
Drives a real key-level `rate_limit: {rpm: 1}` through a real binary and
asserts the refused request's row carries status 429, the member, an
error class that distinguishes a gateway refusal from an upstream one,
and zero billed tokens.
Ref api7/AISIX-Cloud#1389
|
Warning Review limit reached
On-demand reviews are free for the next 23 days. After that, they cost $0.25 per reviewed file. Or wait 10 minutes for your next included review. View limit detailsLimit details: You’ve used the included review currently available. Your 62 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
Comment |
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
1 participant
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.
Follow-up coverage for api7/AISIX-Cloud#1389, extending the member-attribution spec #1066 added.
A 429 reaches a caller two ways: the upstream throttled us, or the gateway's own rate limit refused the request before any upstream was contacted. Only the first is an upstream attempt. The gateway's own refusal leaves the failure path with zero attempts, so it is emitted by a different branch —
chat.rs'smatch chargezero-attempt arm rather than its per-attempt loop — and nothing covered that branch."Show me this member's 429s" needs both to work, and the gateway's own refusals are the more likely half of the question in practice.
Why a test rather than a comment
Reading the emit code makes it easy to conclude the zero-attempt case produces nothing at all:
emit_failed_attemptsis right there, it iteratesrouting.attempts, and that list is empty for a pre-dispatch rejection. The arm that actually emits sits ~30 lines further down, past the loop. I reached the wrong conclusion from exactly that read while working on #1389, and only a real request settled it.What it drives
A real key-level
rate_limit: {rpm: 1}on a member-owned key, through a realaisixbinary: the first request succeeds, the second is refused by the gateway. The refused request's row must carrystatus_code = 429,user_id, so the Logs member filter finds it,error_class = rate_limit_exceeded— what lets an operator tell "we throttled them" from "the provider throttled us",plus a
{user_id, status="429"}increment onaisix_usage_events_emitted_total.No production code changes.
Ref api7/AISIX-Cloud#1389