Aias00 opened a new issue, #6777: URL: https://github.com/apache/shenyu/issues/6777
- Severity: Medium - Location: `shenyu-register-center/shenyu-register-client/shenyu-register-client-api/src/main/java/org/apache/shenyu/register/client/api/FailbackRegistryRepository.java:126` (meta key), `:140` (uri key), `:154` (apiDoc key), `:169` (mcp key), `:175-184` (addToFail skip) - Description: `addToFail` builds the failback key from a field subset that omits `namespaceId` (and per type, methodName/serviceName/parameterTypes/contextPath/ruleName/appName/version): meta key = `rpcType://host:port/path`; uri key = `host:port:rpcType`; apiDoc key = `contextPath:apiPath:httpMethod:rpcType`; mcp key derives from the embedded `MetaDataRegisterDTO` without namespaceId. When a Holder already exists for a key, `addToFail` returns immediately (`:177-179`): (a) a *different* DTO colliding on the coarse key is never enqueued, and (b) a *newer* version (updated rpcExt/status/instanceInfo/version) is discarded, so `accept()` later persists the *stale* original. The DTOs' own `equals/hashCode` include namespaceId and far more fields — the dedup key is inconsistent with DTO identity. - Impact: Failed metadata/uri/apiDoc/mcp registrations for one namespace/variant are silently dropped from failback, or retried with stale content; never persisted until the client happens to re-register. - Suggested fix: Derive the key from the same fields the DTO's `equals/hashCode` use (or use the DTO's `hashCode()`); on collision, *replace* the stored Holder with the newer payload instead of skipping. - Confidence: High - Related existing: none. FUNC-E3 is the server-side URI batch namespace bug; this is the client-side failback dedup key. #4801 is the server-side `FallbackShenyuClientRegisterService` stale-retry (different class). FUNC-E1/E2 are exhaustion/race, not coarse-key dedup. --- _Identified during the 2026-08-02 deep re-scan; full list in [`docs/scan2-2026-08-02/06-medium-tiers.md`](docs/scan2-2026-08-02/06-medium-tiers.md)._ -- 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]
