[konlue]

Fixes #7711.

Summary

The Spring SDK's central response handler has inconsistent status validation: the typed path accepts only 200 OK, so successful 201/202/204 responses throw HttpClientErrorException; and void methods return before any status check, so a 500 is reported to the caller as normal completion. The raw ShenyuResponse return type is an intentional escape hatch and is left untouched.

Modifications

• Classify the response status before decoding: accept the full 2xx range (HttpStatus.resolve(status).is2xxSuccessful()), then handle the raw-response escape hatch, void methods and typed body decoding in that order.
• void methods now throw HttpClientErrorException for non-2xx responses instead of silently succeeding.
• Typed methods still decode the body only when present, so 204 No Content yields null.

Verifying this change

• New tests: handlerResponseAcceptsAllSuccessfulStatuses (200/201/202 decode, 204 null), handlerResponseThrowsForNonSuccessfulStatusesOnTypedMethods (400/500), handlerResponseValidatesVoidMethods (500 throws, 204 null) and handlerResponseReturnsRawResponseRegardlessOfStatus (raw response returned as-is on 500).

• Red-green: the 201 case fails with HttpClientErrorException: 201 CREATED and the void-500 case fails with "expected exception, nothing thrown" on the previous code; all pass with the fix.

• Targeted tests pass:

  ./mvnw -B -ntp -pl shenyu-sdk/shenyu-sdk-spring test -Dtest=ShenyuClientMethodHandlerTest

  4/4 green (the pre-existing JRE-gated test is skipped).

• Checkstyle passes:

  ./mvnw -B -ntp -pl shenyu-sdk/shenyu-sdk-spring checkstyle:check

  clean.

Notes

No change to request construction or transport status propagation. Unknown status codes still surface as HttpStatus.valueOf(...) behaviour, as before.

[Aias00]

LGTM. The reordering is the right fix, and the escape hatch is preserved exactly where it should be.

Evidence

• The new order is null → raw ShenyuResponse → status check → void/empty-body → decode. The raw response still bypasses validation, which is what the class documents as an escape hatch, and handlerResponseReturnsRawResponseRegardlessOfStatus pins it with assertSame on a 500.
• isSuccessful uses HttpStatus.resolve(status).is2xxSuccessful(), so 201/202 now decode instead of throwing, and 204 with a typed return yields null through the existing empty-body branch rather than a separate special case.
• void methods moved after the status check, which is the actual bug in #7711: a 500 was previously reported as a normal completion.
• HttpStatus.resolve returning null is handled (treated as failure), so no NPE on exotic codes.
• Only the Spring SDK has this handler (grep handlerResponse across shenyu-sdk), so there is no sibling implementation left inconsistent.

Nits

1. "Accept all 2xx" is implemented as "resolvable and 2xx", so a vendor code such as 299 would still throw even though it is a success by HTTP semantics. If you meant the literal range, status >= 200 && status < 300 is closer; if you meant the enum, the current code is right — please just say which in the PR body.
2. A 5xx still surfaces as HttpClientErrorException rather than HttpServerErrorException. Pre-existing and changing it would break callers' catch blocks, so leaving it is correct — a comment would stop the next reviewer from "fixing" it.
3. HttpStatus.valueOf on an unresolvable code throws IllegalArgumentException from inside the error path; pre-existing, but it now also applies to void methods, which previously never reached that line.