HY-love-sleep opened a new issue, #7139: URL: https://github.com/apache/shenyu/issues/7139
### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior The `it` workflow has been red on `master` since `cd514ff29` (the merge of #7131), and every PR branched from the current `master` inherits this failure. Failing job: `build (shenyu-integrated-test-http)` → step `Check test result` - master: https://github.com/apache/shenyu/actions/runs/35500859343/job/106057740681 - an affected PR: https://github.com/apache/shenyu/actions/runs/35503510881/job/106059339178 ```text [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.09 s <<< FAILURE! - in org.apache.shenyu.integrated.test.http.combination.ModifyResponsePluginTest [ERROR] org.apache.shenyu.integrated.test.http.combination.ModifyResponsePluginTest.test Time elapsed: 0.015 s <<< ERROR! java.lang.NullPointerException: Cannot invoke "com.google.gson.JsonElement.getAsBoolean()" because the return value of "com.google.gson.JsonObject.get(String)" is null at org.apache.shenyu.integrated.test.http.combination.ModifyResponsePluginTest.test(ModifyResponsePluginTest.java:160) [ERROR] Tests run: 99, Failures: 0, Errors: 1, Skipped: 5 ``` ### Expected Behavior The `it` workflow should be green on `master`, and a response that carries JSON with body rules configured should still be modified — or the integration test should be updated to match the newly intended semantics. ### Steps To Reproduce 1. Check out `cd514ff29` (current `master`) 2. Run the `it` workflow, job `build (shenyu-integrated-test-http)` 3. `ModifyResponsePluginTest.test` fails with the NPE above ### Root cause 1. `ModifyResponsePluginTest.java:160` asserts that the body rules were applied: `assertTrue(body.get(ADD_BODY_KEYS).getAsBoolean());` 2. The endpoint behind this test is `/http/test/modifyResponse` in `shenyu-examples-http` (`HttpTestController`). It returns a JSON string from a `Mono<String>` handler that does not declare `produces`: ```java @GetMapping(path = "/modifyResponse") public Mono<String> modifyResponse(final ServerWebExchange exchange) { ... return Mono.just(GsonUtils.getInstance().toJson(body)); } ``` Spring WebFlux therefore labels the response `text/plain;charset=UTF-8`, even though the payload is JSON. 3. #7131 added this guard at the top of `ModifyResponseDecorator.writeWith`: ```java if (!hasBodyModifications() || !isJsonResponse()) { return super.writeWith(body); } ``` `isJsonResponse()` only returns `true` when the content type is absent, is `application/json`-compatible, or has a `+json` subtype. For `text/plain` it returns `false`, so body modification is now skipped: `addBodyKeys` is never injected, `JsonObject.get("addBodyKeys")` returns `null`, and line 160 throws NPE. `hasBodyModifications()` itself is `true` in this scenario (the test rule sets addBodyKeys / replaceBodyKeys / removeBodyKeys), so the second condition of the guard is what changed the behaviour. ### Regression window The `it` workflow was green on the preceding commits and turned red exactly at `cd514ff29`: | commit | `it` workflow | | --- | --- | | `cd514ff29` fix(modify-response): preserve non-json bodies (#7131) | ❌ failure | | `dc078f08f` fix(ai): bound token usage response buffer (#7124) | ✅ success | | `da970e924` chore(AI): Rename CLAUDE.md to AGENTS.md (#7134) | ✅ success | ### Possible fixes 1. Declare the real content type on the example endpoint — `@GetMapping(path = "/modifyResponse", produces = MediaType.APPLICATION_JSON_VALUE)` — which keeps the existing assertions valid; 2. Or update `ModifyResponsePluginTest` to assert the behaviour introduced by #7131 (non-JSON body preserved) and keep the body-rule coverage on a JSON endpoint; 3. Or relax the `isJsonResponse()` check if the intent is to modify any body that parses as JSON — though that partly contradicts the goal of #7131. ### Environment - `master` @ `cd514ff29` - GitHub Actions, workflow `it`, job `build (shenyu-integrated-test-http)` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
