Marandi269 commented on issue #1168:
URL:
https://github.com/apache/rocketmq-clients/issues/1168#issuecomment-3712790384
## Update: Root Cause Analysis Complete
After further debugging, I found the actual root cause is more nuanced than
initially described.
### The Real Problem
Two issues combine to cause this bug:
1. **Incorrect nesting**: `reset_setting()` was placed inside the `if
res.settings.metric:` block
2. **Exception propagation**: `reset_metric()` throws an exception
(`'NoneType' object has no attribute 'get_meter'`) when `client_metrics` is not
fully initialized
Even after fixing the nesting issue, if `reset_metric()` executes before
`reset_setting()` and throws an exception, the entire async coroutine is
interrupted by the outer `except Exception` handler, and `reset_setting()`
never gets called.
### Debug Output
```
DEBUG: metric check passed
DEBUG: reset_metric exception: 'NoneType' object has no attribute 'get_meter'
DEBUG: calling reset_setting
DEBUG: reset_setting done
```
### Fix
The simplest fix is to call `reset_setting()` **before** `reset_metric()`:
```python
# Before (problematic)
if res.settings and res.settings.metric:
self.__handler.reset_metric(res.settings.metric)
self.__handler.reset_setting(res.settings)
# After (fixed)
if res.settings:
self.__handler.reset_setting(res.settings) # Call first
if res.settings.metric:
self.__handler.reset_metric(res.settings.metric)
```
This ensures consumer initialization completes regardless of metric state.
### Verification
Tested locally with RocketMQ 5.1.4:
- Before fix: `PushConsumer: 0 messages`
- After fix: `PushConsumer: 25 messages`
PR #1169 has been updated with this fix.
--
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]