Aias00 opened a new issue, #7790:
URL: https://github.com/apache/shenyu/issues/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:
```text
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:
```java
service.event("ns", "/ns" + DefaultPathConstants.META_DATA + "/%2Fapi",
null, "/ns" + DefaultPathConstants.META_DATA, EventType.DELETE);
```
Observed:
```text
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](https://github.com/apache/shenyu/blob/b2bc43376a0146684faf6d45a6832d201fc61f45/shenyu-sync-data-center/shenyu-sync-data-api/src/main/java/org/apache/shenyu/sync/data/core/AbstractNodeDataSyncService.java#L286):
ID-only deletion record and subscriber call preceding listener removal.
-
[AbstractPathDataSyncService.java:170](https://github.com/apache/shenyu/blob/b2bc43376a0146684faf6d45a6832d201fc61f45/shenyu-sync-data-center/shenyu-sync-data-api/src/main/java/org/apache/shenyu/sync/data/core/AbstractPathDataSyncService.java#L170):
path-only deletion record.
-
[MetaDataCache.java:103](https://github.com/apache/shenyu/blob/b2bc43376a0146684faf6d45a6832d201fc61f45/shenyu-plugin/shenyu-plugin-base/src/main/java/org/apache/shenyu/plugin/base/cache/MetaDataCache.java#L103):
assumes an ID and path are both present.
-
[MetaDataCache.java:153](https://github.com/apache/shenyu/blob/b2bc43376a0146684faf6d45a6832d201fc61f45/shenyu-plugin/shenyu-plugin-base/src/main/java/org/apache/shenyu/plugin/base/cache/MetaDataCache.java#L153):
null path dereference during invalidation.
-
[MetaDataCache.java:186](https://github.com/apache/shenyu/blob/b2bc43376a0146684faf6d45a6832d201fc61f45/shenyu-plugin/shenyu-plugin-base/src/main/java/org/apache/shenyu/plugin/base/cache/MetaDataCache.java#L186):
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`.
- #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.
- #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.
--
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]
