[konlue]

Fixes #7790.

Summary

Gateway metadata deletion events can carry only half of the identity: AbstractNodeDataSyncService#unCacheMetaData publishes an id-only record, and AbstractPathDataSyncService publishes a path-only record. MetaDataCache#remove assumed both fields were present, so it either threw on clean(null) after removing the id entry (leaving stale positive path results behind and aborting the subsequent removeListener), or threw on ConcurrentHashMap.remove(null) before anything was evicted.

Modifications

• MetaDataCache#remove now resolves the partial identity against the cached canonical record before eviction: with an id it looks up the record for its path; with only a path it finds the record by path and removes it from the id map (otherwise the lazily rebuilt path index would resurrect the entry on the next obtain).
• clean runs with the resolved path (event path first, cached record's path as fallback); when neither can be resolved the removal is a no-op, keeping it idempotent.
• The sync services are intentionally untouched — fixing the cache layer covers both producers and any future half-identity publisher, and once unSubscribe stops throwing, the listener cleanup after it resumes unblocked.

Verifying this change

• shouldRemoveByIdOnlyRecordWithoutPath: id-only removal no longer throws and obtain(path) returns null. Fails on the previous code (NullPointerException from clean(null)).

• shouldRemoveByPathOnlyRecordWithoutId: path-only removal no longer throws and obtain(path) returns null. Fails on the previous code (NullPointerException from remove(null)).

• Full-record removal regression and idempotency (shouldBeIdempotentForPartialRecords) — MetaDataCacheTest 5/5 green.

• Checkstyle passes:

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

  clean.

Notes

The by-path lookup scans the id map once and only runs on the path-only deletion variant — a low-frequency admin operation — so no performance claim is made. The wildcard clear (clean with a * path) behavior is unchanged.

[Aias00]

Clean fix for #7790. Deletion events can carry only half the identity (id without path, or path without id), and the previous remove(...) would throw or miss the derived path entry. Resolving the partial identity against the cached canonical record and keeping the removal idempotent is the right call.

Highlights:

• findByPath(...) resolves the cached record so both the id map and the derived path index are invalidated, regardless of which half of the identity the event carries.
• The four new tests (id-only, path-only, full record, idempotent partial) cover the cases well, including the no-op path on missing records.

pr_build is green. Approving.