[hanzhe-one]

Problem

master is red on build (shenyu-integrated-test-http) since #7903. CryptorResponsePluginTest.testWhenDoesntExistFiled asserts that a rule whose fieldNames matches nothing returns the original body, but #7903 deliberately changed that contract:

protected String fieldErrorParse(final String originalBody, final ServerWebExchange exchange) {
    ShenyuResultEnum resultEnum = checkErrorEnum();
    throw new ResponsiveException(resultEnum.getCode(), resultEnum.getMsg() + "[fieldNames]", exchange);
}

The gateway now answers {"code":-116,"message":"Please check Cryptor response plugin's [fieldNames]"}, so the test's postGateway(..., UserDTO.class) deserializes to an object with a null userId and the assertion fails. #7903 validated only the cryptor module's unit tests, so the stale integrated test reached master.

Evidence on the master push for 679a9eb69cb5fc61f1ae242c8f5bdd4011ead8f7: job 119079963808. Reported as #7968.

Change

• Assert CRYPTOR_RESPONSE_ERROR_CONFIGURATION.getCode() and .getMsg() + "[fieldNames]" instead of the original body, mirroring how CryptorRequestPluginTest already asserts the request-side configuration error.
• Rename testWhenDoesntExistFiled to testWhenFieldDoesNotExistInResponse and update its @DisplayName, which still described the passthrough behavior.

Only the test changes; the plugin behavior introduced by #7903 is kept.

Validation

• shenyu-integrated-test-http compiles (mvn -pl shenyu-integrated-test-http -am test-compile).
• Checkstyle passes for the module.
• The integrated suite needs the Docker environment used by CI, so the run itself is left to the workflow.

Fixes #7968

[Aias00]

Review: #7970 test(cryptor): assert the configuration error for a missing response field

Verdict: approved — this is the correct fix for a real master breakage, and the diagnosis in the PR body is right.

Why this is needed (I confirmed it independently)

I had assumed master's it was healthy because run 39603998075 on be34dd1e concluded success. That was wrong, and this PR made me re-check it:

$ gh api repos/apache/shenyu/actions/runs/39603998075/jobs
success | changes
skipped | build

The build job was skipped by the path filter, so shenyu-integrated-test-http had not been exercised since #7903 landed. Master's it workflow is green only in the sense that nobody has run the affected module. Every build (shenyu-integrated-test-http) failure on the open PRs is therefore the same live regression, not a stale run — which makes this patch the thing that unblocks that whole queue of PRs.

I verified the source side too: CryptorResponsePlugin.fieldErrorParse throws ResponsiveException(CRYPTOR_RESPONSE_ERROR_CONFIGURATION.getCode(), getMsg() + "[fieldNames]", exchange), AbstractCryptorPlugin.convert routes a null conversion result into fieldErrorParse, and CryptorResponsePlugin.doExecute0 maps any ResponsiveException out of the chain into WebFluxResultUtils.failedResult. So a rule whose fieldNames matches nothing really does produce {"code":-116,"message":"... [fieldNames]"} rather than a passthrough. The old assertion could only pass while the plugin did not run at all.

What the change does

• Asserts ${CRYPTOR_RESPONSE_ERROR_CONFIGURATION.getCode()} and .getMsg() + "[fieldNames]" instead of deserialising the body into UserDTO and comparing userId/userName. Deserialising into AdminResponse is the right receiver: the body is an error envelope, and reading it as UserDTO is what silently turned the failure into null == null-adjacent noise.
• Renames testWhenDoesntExistFiled → testWhenFieldDoesNotExistInResponse and fixes the @DisplayName, which still promised "return original message". A test whose name states the opposite of the contract is worse than no test, because the next person reads the name and believes the passthrough is intended.
• Adds a comment tying the assertion to #7903 so the why survives the next refactor.
• Uses a static import for CRYPTOR_RESPONSE_ERROR_CONFIGURATION alongside the existing DECRYPTION_ERROR / ENCRYPTION_ERROR imports, matching the file's existing style.

Non-blocking

• CryptorRequestPluginTest already asserts the request-side equivalent; the two files now describe the same contract from both directions, which is worth mirroring in a comment on the request side later. No action here.
• #7946 carries an overlapping fix for the same test (parameterised over decrypt/encrypt). Only one of the two can land first; whichever lands second should drop its copy of this hunk rather than conflict. This one is narrower and more likely to merge cleanly, so I would take this one first and have #7946 rebase.
• The @Test here covers only decrypt. The encrypt direction reaches the same fieldErrorParse through CryptorResponsePlugin, so the coverage is adequate, but the parameterised form in #7946 is marginally stronger if you ever rebase these together.

CI is queued on the current head; the change is a single test method against an unchanged production contract.

[hanzhe-one]

/retest

[Aias00]

Ping on state: this PR is approved on the code, but it now conflicts with master, so it cannot be merged as is.

Please rebase onto current master (or merge master into your branch) and push. The "Update branch" button cannot resolve these conflicts. After the push the required checks will re-run; if any of them still fail for the shared e2e reasons, a rerun of the failed jobs is enough.

[hanzhe-one]

Thanks for the ping. The conflict has a specific cause: master already contains a fix for the same test, so rebasing this PR would leave it with an empty diff.

8534c4644 (#7941, merged 2026-10-23) carries 75b99e0c8 test(ci): align cryptor failures and wait for usable SDK routes, which rewrote CryptorResponsePluginTest.testWhenDoesntExistFiled into:

@ParameterizedTest
@ValueSource(strings = {"decrypt", "encrypt"})
@DisplayName("reject a response missing the configured field")
public void testWhenConfiguredFieldDoesNotExist(final String way) throws Exception {
    ...
    assertThat(response.getCode(), is(error.getCode()));
    assertThat(response.getMessage(), is(error.getMsg() + "[fieldNames]"));
    assertThat(body, not(containsString(TEST_USER_ID)));
    assertThat(body, not(containsString(TEST_USER_NAME)));
}

That is a superset of what this PR does: same assertion on CRYPTOR_RESPONSE_ERROR_CONFIGURATION and the [fieldNames] suffix, plus parameterisation over decrypt/encrypt and checks that the original user data is absent from the response. I confirmed the conflicting hunk is exactly this method and nothing else; every other file merges cleanly.

So resolving the conflict in master's favour would leave this branch with no changes, and keeping my version would revert the stronger parameterised coverage. Neither is worth merging, and #7941 already unblocks the shenyu-integrated-test-http queue this PR was opened for.

This PR can therefore be closed without merging; issue #7968 describes the same regression and can be closed for the same reason. Thanks for the review and for the careful check on the skipped build job in 39603998075 — that diagnosis was correct and is what pointed at #7941.

[yuluo-yx]

hi @hanzhe-one please resolve conflicts

[yuluo-yx]

/hold

[Aias00]

@hanzhe-one Heads-up: this PR is approved and every check is green, so the only thing blocking the merge is the merge conflict GitHub reports (mergeable: false).

Please rebase onto current master and push. I'll merge as soon as the PR reports clean again.

[hanzhe-one]

I ran the rebase on a scratch branch to see what it produces, and neither resolution works. Reproducible below.

Resolving in favour of master leaves an empty diff:

$ git checkout --ours shenyu-integrated-test/.../CryptorResponsePluginTest.java
$ git add shenyu-integrated-test/.../CryptorResponsePluginTest.java
$ git diff --cached origin/master --stat
(no output)

Resolving in favour of this branch reverts master's stronger version:

-    @ParameterizedTest
-    @ValueSource(strings = {"decrypt", "encrypt"})
-    public void testWhenConfiguredFieldDoesNotExist(final String way)
+    @Test
+    public void testWhenFieldDoesNotExistInResponse()

8534c4644 (#7941) already rewrote this exact method, and it is the last commit touching the file:

$ git log -1 --format="%h %s" origin/master -- shenyu-integrated-test/.../CryptorResponsePluginTest.java
8534c4644 fix(admin): serialize default selector registration across Admins (#7941)

So there is nothing left to merge here: the conflict exists only because both branches rewrote the same method, and master's rewrite is a superset of mine. Closing this PR is the correct outcome, and I see the hold label is already applied. Issue #7968 was closed by @Aias00 for the same reason.

Sorry for the noise on this one — I should have found #7941's test(ci): align cryptor failures commit before opening the PR.

[Aias00]

Hi @hanzhe-one, this PR is already approved, but it currently cannot be merged. Here is the blocker and what is needed:

Blocker
This PR is unmergeable (conflict) against master.

What we need
Please rebase onto the latest master, resolve conflicts, and re-push.

Once the branch is up to date and CI is green, we will squash-merge it. Thanks!