[dengliming]

Summary

• rebuild each auth path with its own DTO appName
• remove the stale first-old-path appName lookup
• add regression coverage for multiple paths with different app names

Testing

• JAVA_TOOL_OPTIONS=-javaagent:<byte-buddy-agent> mvn -pl shenyu-admin -am -DskipTests=false -Dcheckstyle.skip=false -Dtest=AppAuthServiceTest -DfailIfNoTests=false test

Fixes #6539

[Copilot]

🟢 Approval recommended

The focused fix matches the reported behavior and includes effective regression coverage.

Pull request overview

Fixes #6539 by preserving each authorization path’s application name during updates.

Changes:

• Rebuilds paths using each DTO’s appName.
• Adds regression coverage for paths with different application names.

File summaries

File	Description
AppAuthServiceImpl.java	Removes stale app-name lookup and preserves per-path values.
AppAuthServiceTest.java	Verifies distinct app names are persisted.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 0
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Aias00]

Approved as PMC (Aias00). Small, well-scoped fix with regression tests; green CI, mergeable. Reviewed the diff.

[Aias00]

Re-reviewed: preserving auth path application names instead of dropping them is a small, correct fix with a test. Approving.

[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]

@dengliming This PR is approved, but 5 checks are red: e2e, e2e-case (e2e-logging-rocketmq-compose, shenyu-e2e-case-logging-rocketmq, :shenyu-examples-http), e2e-case (e2e-springcloud-sync-compose, shenyu-e2e-case-spring-cloud, :shenyu-examples-eureka,:sh..., e2e-case (e2e-apache-dubbo-sync-compose, shenyu-e2e-case-apache-dubbo, :shenyu-examples-apache-du... (+1 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.

[Aias00]

@dengliming — a correction to the note I left here yesterday. The failures on this branch all predate the fix, so nothing in your change is implicated.

master went green at a8080ae: the SubscribeTest fixture isolation (#8092), the MQTT session scoping (#8093) and the pr_build dependency fix (#8075) all landed, and the latest ci.yml, integrated-test.yml and CodeQL runs on master are all success.

That means the red checks recorded here are stale. A push — an empty commit or a rebase, whichever is easier — re-runs them against the current baseline. I would not spend time reading the old logs.

For the e2e jobs specifically: /retest on a run whose shenyu-images artifact has expired now falls back to a full rerun and rebuilds it (#8094 landed), so that path works again too.

[Aias00]

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

Blocker
This PR is approved but currently blocked. The CI runs are stale (last run 2026-09-30) against an old base; the e2e / e2e-grpc-sync-compose failures come from that old base and are not clearly caused by your diff.

What we need
Please rebase onto current master and re-trigger CI. If the e2e failure reproduces after rebase, paste the failing case so we can triage.

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