fix(proxy): fall back to max long polling timeout when gRPC deadline is absent

[zjncs]

Motivation

ContextInitPipeline only records the remaining deadline time when the gRPC call actually carries a deadline. For a call without one — which gRPC allows — ctx.getRemainingMs() returned null and the unboxing in the polling-time computation threw a NullPointerException, which the catch block turned into an INTERNAL_SERVER_ERROR response.

Modifications

Treat an absent deadline as grpcClientConsumerMaxLongPollingTimeoutMillis remaining time, so polling time and the timeout passed to popMessage stay bounded by the configured maximum instead of crashing.

Verification

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

ReceiveMessageActivityTest#testReceiveMessageWithoutDeadline
java.lang.AssertionError: expected:<MESSAGE_NOT_FOUND> but was:<INTERNAL_SERVER_ERROR>
  ReceiveMessageActivityTest.testReceiveMessageWithoutDeadline:456
(root cause: NullPointerException on "Long.longValue()" because "timeRemaining" 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

Fall back to grpcClientConsumerMaxLongPollingTimeoutMillis when the gRPC deadline is absent (null remainingMs), instead of relying on auto-unboxing which would throw NPE.

LGTM — clean null safety fix.

---

Automated review by github-manager-bot