Aias00 opened a new issue, #7454:
URL: https://github.com/apache/shenyu/issues/7454
## Is there an existing issue for this?
- [x] I searched open and closed issues.
## Current Behavior
RabbitMQ logging does not recreate a selector's custom client after the
selector handle is cleared and later restored to its original value.
The missing/blank-host branch removes the client from `RabbitmqClientCache`,
but leaves the old selector configuration in
`AbstractLogPluginDataHandler.SELECT_API_CONFIG_MAP`. When the original handle
is restored, the configuration equality check sees that stale configuration and
returns before `initRabbitmqClient()`.
## Expected Behavior
Restoring a valid custom selector configuration should recreate the
corresponding client, even if the same configuration was previously used before
switching to global settings.
## Steps To Reproduce
1. Enable RabbitMQ logging with a usable global configuration.
2. Configure one selector with a valid custom RabbitMQ handle `A` and verify
its custom client is created.
3. Update that selector's handle to `{}` to use global settings; its custom
client is removed.
4. Restore exactly the original custom handle `A`.
5. Observe that no custom client is created; logging continues to use the
global client.
6. As a control, change a field in `A` (for example its routing key): a
custom client is then created.
An offline harness compiled the current handler/cache source and used
Mockito constructor mocks only for the broker-facing client. Actual selector
handler/cache methods produced:
```text
initial: customClient=true, constructions=1
cleared: customClient=false, savedConfig=true
restored same: customClient=false, constructions=1
restored changed: customClient=true, constructions=2
```
## Location And Impact
-
[LoggingRabbitmqPluginDataHandler.java:96](https://github.com/apache/shenyu/blob/67596c1d228b62da75cd0a0ecb47d0ac5d995384/shenyu-plugin/shenyu-plugin-logging/shenyu-plugin-logging-rabbitmq/src/main/java/org/apache/shenyu/plugin/logging/rabbitmq/handler/LoggingRabbitmqPluginDataHandler.java#L96):
invalidates the client without removing saved selector configuration.
-
[LoggingRabbitmqPluginDataHandler.java:104](https://github.com/apache/shenyu/blob/67596c1d228b62da75cd0a0ecb47d0ac5d995384/shenyu-plugin/shenyu-plugin-logging/shenyu-plugin-logging-rabbitmq/src/main/java/org/apache/shenyu/plugin/logging/rabbitmq/handler/LoggingRabbitmqPluginDataHandler.java#L104):
the stale equality check suppresses client restoration.
-
[RabbitmqLogCollector.java:58](https://github.com/apache/shenyu/blob/67596c1d228b62da75cd0a0ecb47d0ac5d995384/shenyu-plugin/shenyu-plugin-logging/shenyu-plugin-logging-rabbitmq/src/main/java/org/apache/shenyu/plugin/logging/rabbitmq/conllector/RabbitmqLogCollector.java#L58):
missing selector clients fall back to the global client.
Severity: Medium. Confidence: high. Coverage: confirmed offline
handler/cache lifecycle behavior.
The selector appears to have its custom destination restored, but its logs
use the global destination instead. If the global client is unavailable, this
also prevents delivery through the otherwise valid restored custom
configuration.
## Suggested Fix And Regression Coverage
Remove saved selector API configuration when reverting to global settings,
and/or require a live matching cached client before skipping initialization for
equal configuration. Keep selector configuration, client cache and multi-client
mode consistent.
Add a regression for custom `A` -> empty/global -> identical custom `A`,
asserting the old client closes and a new custom client is constructed. Retain
unchanged-live-config and different-config controls.
## Validation And Related Issues
Reviewed `master` at `67596c1d228b62da75cd0a0ecb47d0ac5d995384`
(`2.7.2-SNAPSHOT`). Leader runtime reproduction and an isolated verifier's
source review confirmed the issue. Existing
`LoggingRabbitmqPluginDataHandlerTest,RabbitmqClientCacheTest`: 9 tests passed;
the restore transition is not covered.
#7307 is the RabbitMQ plugin-store migration task, including general
config-refresh coverage. It does not describe this saved-config/client-cache
inconsistency. No matching runtime restore issue was found.
No real broker/network connection was used by the new reproduction.
--
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]