[BUG] HuaweiLtsLogConfig.equals() omits generic config fields, preventing re-initialization
- Dominant language
- Java
- Stars
- 8.8k
- Forks
- 3.1k
- Avg merge
- 7d 1h
- Merged PRs (30d)
- 85
Description
- severity: Medium
- files: `shenyu-plugin/shenyu-plugin-logging/shenyu-plugin-logging-huawei-lts/.../HuaweiLogCollectConfig.java:448-473`
- description: `HuaweiLtsLogConfig.equals()` checks all Huawei-specific fields but does NOT include `getSampleRate()`, `getBufferQueueSize()`, `getMaxRequestBody()`, or `getMaxResponseBody()` from the parent `GenericGlobalConfig`. Compare with `KafkaLogConfig.equals()` and `ClickHouseLogConfig.equals()` which DO include these. `AbstractLogPluginDataHandler.handlerPlugin()` uses `!globalLogConfig.equals(exist)` to control `doRefreshConfig`/`logCollector().start()`.
- impact: Changes to `bufferQueueSize`, `maxRequestBody`, or `maxResponseBody` in Huawei LTS config do not take effect until plugin disabled/re-enabled.
- suggested_fix: Add the parent config fields to equals/hashCode.
- confidence: High
- related_existing: none
---
_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)._
Contributor guide
No contributing guide indexed for this repository
Research direction
Start in shenyu-plugin/shenyu-plugin-logging/shenyu-plugin-logging-huawei-lts/.../HuaweiLogCollectConfig.java:448-473 and compare HuaweiLtsLogConfig.equals() with KafkaLogConfig.equals() and ClickHouseLogConfig.equals(). Check how AbstractLogPluginDataHandler.handlerPlugin() uses equality for doRefreshConfig and logCollector().start(); done means the generic config fields participate in equals/hashCode so Huawei LTS changes are detected.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- observability
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 76/100