[BUG] Partial metadata deletion events throw and leave stale gateway metadata caches #7790

Current Behavior

Gateway metadata deletion requires both the metadata ID and path, but the sync services publish partial deletion records. Consequently, a normal delete event throws NullPointerException and leaves stale metadata available to path lookups.

There are two variants of the same producer/consumer contract mismatch:

• AbstractNodeDataSyncService.unCacheMetaData constructs a record containing only the correct ID, then passes it to subscribers. MetaDataCache.remove removes the ID entry, but calls clean(null), which dereferences the absent path. Existing positive path-cache entries survive. The exception also prevents the subsequent removeListener call.
• AbstractPathDataSyncService constructs a record containing only the decoded path. MetaDataCache.remove first calls ConcurrentMap.remove(null), which throws before removing either cache entry.

MetaDataCacheSubscriber.unSubscribe forwards both records without enriching them. Marking the index dirty does not fix the first variant: obtain can return an existing positive path-cache result before rebuilding the index.

Expected Behavior

Metadata deletions from supported sync channels should evict the canonical metadata and its derived path results without requiring fields absent from their deletion events. Unknown/already-removed records should be harmless.

Reproduction

Using current production source classes:

1. Cache enabled metadata with ID metadata-id and path /api; call obtain("/api") to confirm the path hit.
2. With a minimal AbstractNodeDataSyncService subclass and a real MetaDataCacheSubscriber, invoke the protected deletion helper for namespace-a.meta.metadata-id. The subclass only supplies the external configuration hook and records listener removal.
3. Catch the exception, inspect the ID map, then call obtain("/api") again.

Observed:

BEFORE pathHit=true
DELETE_EXCEPTION=NullPointerException
AFTER idPresent=false pathHit=true listenerRemoved=false
FULL_RECORD_CONTROL pathHit=false

The control calls remove with the original full metadata record, which clears the stale result.

For the path-based variant, seed the same metadata and invoke the real public event dispatcher:

service.event("ns", "/ns" + DefaultPathConstants.META_DATA + "/%2Fapi",
        null, "/ns" + DefaultPathConstants.META_DATA, EventType.DELETE);

Observed:

PATH_DELETE_EXCEPTION=NullPointerException
PATH_AFTER idPresent=true pathHit=true

Both probes compile the relevant current production sync/cache/subscriber sources. No external config-center deployment was used; the path probe exercises the actual event dispatcher, while the node probe exercises its actual deletion helper.

Location

• AbstractNodeDataSyncService.java:286: ID-only deletion record and subscriber call preceding listener removal.
• AbstractPathDataSyncService.java:170: path-only deletion record.
• MetaDataCache.java:103: assumes an ID and path are both present.
• MetaDataCache.java:153: null path dereference during invalidation.
• MetaDataCache.java:186: existing positive results are returned from the path cache.

Impact And Suggested Fix

Deleted metadata can remain effective on gateways using node/path sync. Nacos/Apollo use the node base service; etcd/Zookeeper use the path base service. This is a cache/data-correctness issue, with a local exception on the delete path.

Resolve partial deletion identities against the cached canonical record before discarding it, and invalidate all derived results associated with removed records. For path-only records, resolve the corresponding stored ID(s) according to the metadata identity contract. Adding only a null-path guard would leave stale positive results in the node variant. Keep deletion idempotent and avoid leaving listener cleanup blocked by an absent record.

Priority: P2 / Medium. Confidence: high for the executed producer/subscriber/cache paths. No live backend callback or complete gateway integration deployment was run.

Environment And Related Issues

Apache ShenYu 2.7.2-SNAPSHOT, master at b2bc43376a0146684faf6d45a6832d201fc61f45.

• [BUG] Node sync auth and metadata deletes unsubscribe the wrong cache key #6478 concerns extracting the wrong segment from a node key. In this revision the node producer already uses metaKeys[2], the correct ID; the failure above remains because the consumer requires an absent path. The path-only variant does not use that key splitting at all.
• [BUG] MetaDataCache: unbounded CACHE (maximumSize=Integer.MAX_VALUE) + MAPPING Set never shrunk #6565 concerns cache bounds; this issue concerns invalidation correctness and exceptions on normal deletions.
• Open and closed issue searches and current open PR titles were checked before filing.