[BUG] Spring SDK rejects non-200 successful responses and skips error checks for void methods #7711

Current behavior

The Spring SDK's central response handler has inconsistent status validation:

• Typed DTO/scalar methods accept only 200 OK, so successful 201 Created, 202 Accepted and 204 No Content throw HttpClientErrorException.
• Methods declared void return before any status validation, so even 500 Internal Server Error is silently reported to the caller as normal completion.
• Returning the raw ShenyuResponse intentionally exposes the response directly; that explicit raw-response escape hatch is not the issue.

Location / reachable flow

ShenyuClientMethodHandler.java:71–89.

Public invoke() builds the request, calls ShenyuSdkClient.execute() and passes its actual status into this handler. Both HTTP SDK transports retain upstream status codes, so ordinary REST create/delete operations reach these branches.

Reproduction and validation

A standalone Java probe compiled the current handler source and called its public invoke() with an otherwise valid RequestTemplate and an in-process SDK transport returning fixed responses:

STATUS=200 RESULT=ok
STATUS=201 EXCEPTION=HttpClientErrorException:201 CREATED
STATUS=202 EXCEPTION=HttpClientErrorException:202 ACCEPTED
STATUS=204 EXCEPTION=HttpClientErrorException:204 NO_CONTENT
STATUS=400 EXCEPTION=HttpClientErrorException:400 BAD_REQUEST
VOID_STATUS=500 RESULT=null

The 200/400 results are controls. No gateway deployment was required; this is an SDK conversion-path reproduction. An independent reviewer confirmed the typed/void/raw-response branch boundaries and transport caller flow.

Impact / expected behavior

Normal successful REST responses fail client-side, while failures of fire-and-forget-style void methods can be ignored. Validate success consistently for the full 2xx range before typed/void conversion; a 204 response should produce no body value, and non-success void responses should not silently succeed. Preserve deliberate raw-response access semantics.

Suggested fix

Separate response-status classification from return-value decoding. Handle all successful 2xx responses, apply error handling to void methods, and then decode a present body only when the declared return type requires it.

Related existing work

Searched the complete 3,093-issue title baseline, open PR titles and live handler/status queries. #6853 concerns transport exception wrapping that disabled retries; #7466 concerns Object methods routed remotely; #7464 concerns query encoding. None covers status classification by this response handler.

Reviewed revision

Apache ShenYu 2.7.2-SNAPSHOT, master@66d7d954ca37d651a5ad916f988a8081157a7ab4. Severity Medium / P2; confidence high. Unit-test and CI issue categories excluded.