Bug: ai-quota leaves completion requests paused when Redis GET dispatch fails synchronously

If this is a potential security issue, please use a GitHub Private Security Advisory. This report concerns request availability; no security impact is claimed.

• I searched the repository's issues and pull requests and believe this is not a duplicate.

I. Issue Description

In ai-quota completion mode, a synchronous Redis GET dispatch failure can leave the HTTP request paused indefinitely. The handler ignores the error returned by RedisClient.Get and returns HeaderStopAllIterationAndWatermark, although no Redis callback was scheduled to resume or reject the request.

II. Describe what happened

At main@b44d4f77011ad7f63c2fefef5b8cd2dec0cff1c6, onHttpRequestHeaders calls config.redisClient.Get(...) without checking its returned error, then always returns HeaderStopAllIterationAndWatermark. The callback is the only path that calls ResumeHttpRequest or sends a quota-denial response.

In the pinned wasm-go SDK, RedisClient.Get can return an error directly, and RedisCall returns a synchronous dispatch error without invoking the callback. The same plugin already checks the Get error for its admin quota query.

This differs from an asynchronous Redis error response, which does reach the callback and is handled as a denial. No panic or stack trace is involved.

III. Describe what you expected to happen

On a synchronous Redis GET failure, complete the request deterministically, for example with an explicit 503 response, rather than returning a pause action with no pending callback. Successful Redis calls should keep the existing quota-check behavior.

IV. How to reproduce it (as minimally and precisely as possible)

1. In a native Go test for ai-quota, inject a RedisClient whose Get returns errors.New("dispatch failed") immediately and does not call its callback.
2. Invoke onHttpRequestHeaders for /v1/chat/completions with x-mse-consumer: consumer1 and an otherwise valid quota configuration.
3. The current handler returns HeaderStopAllIterationAndWatermark, but neither a local response nor ResumeHttpRequest is produced. The expected result is a completed error response, not an indefinite pause.

This negative-path test has not yet been added or run. The existing go test -count=1 -run '^TestOnHttpRequestHeaders$' -v . passed in native Go mode, but covers successful Redis calls, not synchronous dispatch failure. Wasm mode was skipped because main.wasm is absent.

V. Anything else we need to know?

Source-level analysis only; no real Higress/Envoy runtime reproduction, logs, or timing measurement is claimed. PR #4824 touches ai-quota/main.go for admin-query parsing but does not modify this completion-path Get call. AI assistance was used for source inspection and drafting; no fix is included in this issue.

VI. Environment

• Higress version: main@b44d4f77011ad7f63c2fefef5b8cd2dec0cff1c6
• OS: macOS/arm64 for the native Go test
• Others: Go 1.24.4; github.com/higress-group/wasm-go version v1.0.2-0.20250821081215-b573359becf8; no real proxy-Wasm runtime verification yet