[konlue]

Fixes #7736.

Summary

BodyParamUtils#buildParameters takes the legacy whole-body single-argument path whenever the resolved type list has exactly one non-base entry — including a single-entry JSON name mapping. buildSingleParameter then uses the original mapping JSON as the parameter type and keeps the outer parameter-name wrapper in the value, so generic type resolution fails or binds the wrong shape.

Modifications

• Restrict the whole-body shortcut to non-mapped metadata (!isNameMapping(parameterTypes)); name-mapped parameters always use the resolved name/type/value path, regardless of entry count.
• Add BodyParamUtilsTest covering: single-entry mapping → ["java.util.Map"] / bare map argument; multi-entry mapping ordering; plain single bean keeps whole-body semantics; single mapped base type unchanged.

Verifying this change

• Red-green: with the original shortcut restored, testSingleNameMappedParameterUsesResolvedTypeAndValue fails (the type is the mapping JSON and the argument keeps the arg wrapper); with the fix all four tests pass.

• Targeted tests pass:

  ./mvnw -B -ntp -pl shenyu-plugin/shenyu-plugin-api test -Dtest=BodyParamUtilsTest

  4/4 green.

• Checkstyle passes:

  ./mvnw -B -ntp -pl shenyu-plugin/shenyu-plugin-api checkstyle:check

  clean.

Notes

buildSingleParameter itself is unchanged, so any direct caller keeps its behaviour; only the name-mapping branch inside buildParameters changes. Multi-parameter mappings and non-mapped plain-type calls are untouched.

[Aias00]

LGTM. I traced the whole method rather than just the guard, because the risk here is that the map path does not handle a single mapped POJO.

Evidence

• Before: a single-entry mapping fell into buildSingleParameter(body, parameterTypes), which treats the raw {"arg":"..."} JSON as the type name and keeps the arg wrapper in the value. Both halves of the bug are real.
• After: the map path builds paramNameList from the mapping keys and paramTypeList from the mapping values, then for each key takes the body value and converts a JsonObject to Map / a JsonArray to List. So a single mapped POJO now arrives as Map under its declared type — which is the same shape the non-mapped single-bean path produces (testPlainSingleBeanKeepsWholeBodySemantics), i.e. the Dubbo generic-invocation convention is preserved rather than changed.
• A single mapped base type never took the shortcut (isBaseType already excluded it), so that path is provably untouched, and you pin it with a test.
• isNameMapping requires the string to start with { and end with }, so a plain comma-separated type list can never be misclassified.
• buildSingleParameter itself is unchanged, so no other caller shifts behaviour, as the PR body claims.

Nits

1. The shortcut condition is now a three-clause expression and isNameMapping(parameterTypes) is evaluated twice per call (once for the branch above, once here). It is cheap, but a local boolean would read better and cost nothing.
2. Worth one line in the javadoc of buildParameters: "name-mapped metadata never uses the whole-body shortcut" — this is the invariant the next person needs to keep.

CI: pr_build green. The red e2e jobs (http-sync, apache-dubbo, cluster-jdbc/zookeeper, rocketmq) all end with ##[error]The operation was canceled. and every case that actually executed reported Failures: 0 — the workflow was cancelled at ~5 min, so this is infrastructure, not the change. Please rerun e2e before merge.

[Aias00]

Ping on state: this PR is approved on the code, but the required checks are red and it cannot be merged yet.

The failing jobs are e2e / e2e-case / list-contract / native-sql, which are currently failing across the repository and are tracked in #7970. The build job in this run does not fail on compilation: it stops at the gate step that consumes the e2e result ([[ "failure" == "success" ]] || exit -1), so there is nothing in this PR to fix for that.

No code change is expected from you. Once the shared e2e problem is resolved, please rerun the failed jobs (or push a trivial rebase) so the required checks go green, and this can be merged.

[Aias00]

@konlue This PR is approved, but 9 checks are red: e2e, e2e-case (e2e-cluster-zookeeper-compose, shenyu-e2e-case-cluster, :shenyu-examples-http), e2e-case (e2e-springcloud-sync-compose, shenyu-e2e-case-spring-cloud, :shenyu-examples-eureka,:sh..., e2e-case (e2e-grpc-sync-compose, shenyu-e2e-case-grpc, :shenyu-examples-grpc) (+5 more).

I inspected these lanes today and they fail for infrastructure reasons rather than on the diff — the integrated-test jobs die while starting their containers (Elasticsearch /_cat/health returning 000 until the job is cancelled), and the http lane also hits the known CachePluginTest.testMemoryModle / testRedisModle flake. The same jobs are red on master and on unrelated PRs right now.

Please rebase onto master and push (or ask for a re-run) so the checks execute again. If a case is still failing on a fresh run, paste the test name and I'll look properly.

[konlue]

Rebased onto the latest master to re-trigger the checks; the earlier failures were the known infra issues.