[ISSUE #8714]

[zhaohai666]

[ISSUE #8714]

[codecov-commenter]

Codecov Report

❌ Patch coverage is 90.90909% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 48.89%. Comparing base (932588d) to head (cac1baf).
⚠️ Report is 23 commits behind head on develop.

Files with missing lines	Patch %	Lines
...proxy/grpc/v2/consumer/ReceiveMessageActivity.java	88.23%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             develop   #10252      +/-   ##
=============================================
- Coverage      48.99%   48.89%   -0.10%     
- Complexity     13393    13435      +42     
=============================================
  Files           1373     1375       +2     
  Lines          99904   100414     +510     
  Branches       12901    12969      +68     
=============================================
+ Hits           48944    49095     +151     
- Misses         45038    45306     +268     
- Partials        5922     6013      +91     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[qianye1001]

Thanks for looking into this issue, @zhaohai666.

After reviewing the changes, I don't think patching the server side is the right approach here. The settings being null means the client did not establish a proper Telemetry session before calling receiveMessage. Silently falling back to hardcoded defaults on the server masks the real problem and can introduce subtle issues — for example, defaulting fifo=false for a consumer that actually requires FIFO ordering would cause silent data misordering, which is arguably worse than a clear error.

The server is behaving correctly by expecting valid client settings to be present. The proper fix should be on the client side (e.g., the Node.js SDK rocketmq-client-nodejs), ensuring it establishes and maintains the Telemetry session so that settings are always available when receiveMessage is called. The Java client already does this correctly, which is why this issue only surfaces with non-Java SDKs.

Adding defensive null checks on the server to compensate for incomplete client implementations sets a bad precedent — it shifts the contract and could hide future client-side bugs as well.

I'd suggest investigating why the client SDK loses its Telemetry session over time and fixing it there instead.