fix(proxy): return UNRECOGNIZED_CLIENT_TYPE when client settings is null in receiveMessage

[zjncs]

Motivation

A gRPC client that calls ReceiveMessage before any settings were cached (or after its settings were cleaned up) made getClientSettings return null, and the following settings.getClientType() threw a NullPointerException which the catch block turned into an opaque INTERNAL_SERVER_ERROR response.

ClientActivity.heartbeat already guards this case with UNRECOGNIZED_CLIENT_TYPE.

Modifications

Apply the same guard in receiveMessage so the client gets a meaningful code.

Verification

Fail-before (new test, run against the unpatched code):

ReceiveMessageActivityTest#testReceiveMessageWithoutClientSettings
java.lang.AssertionError: expected:<UNRECOGNIZED_CLIENT_TYPE> but was:<INTERNAL_SERVER_ERROR>
  ReceiveMessageActivityTest.testReceiveMessageWithoutClientSettings:447
(root cause: NullPointerException on "Settings.getClientType()" because "settings" is null)

Pass-after:

Tests run: 10, Failures: 0, Errors: 0, Skipped: 0 -- ReceiveMessageActivityTest

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[RockteMQ-AI]

Summary

Add null check for client settings in receiveMessage, returning UNRECOGNIZED_CLIENT_TYPE instead of NPE when settings are not found.

LGTM — proper error handling for missing client configuration.

---

Automated review by github-manager-bot