Aias00 opened a new issue, #10764:
URL: https://github.com/apache/rocketmq/issues/10764

   ### Before Creating the Bug Report
   
   - [x] I have confirmed this problem is not already covered by an existing 
issue or open pull request.
   
   ### Runtime platform environment
   
   Any RocketMQ Proxy local-mode deployment that uses `InvocationChannel` for 
local remoting requests.
   
   ### RocketMQ version
   
   develop branch
   
   ### JDK Version
   
   N/A
   
   ### Describe the Bug
   
   `InvocationChannel.clearExpireContext()` removes expired local invocation 
contexts without completing the response future held by `InvocationContext`.
   
   Local-mode `sendMessage()` and `popMessage()` create a 
`CompletableFuture<RemotingCommand>`, wrap it in `InvocationContext`, and 
register it against the request opaque. If the response is never written back 
and the periodic channel cleanup expires the context, the map entry is removed, 
but the waiting future is left incomplete.
   
   Relevant code paths:
   
   - `InvocationChannel.clearExpireContext()` removes expired entries.
   - `InvocationContext` owns the waiting response future.
   - `LocalServiceManager` schedules periodic `scanAndCleanChannels()`.
   - `LocalMessageService.sendMessage()` and `popMessage()` register these 
invocation contexts.
   
   ### Steps to Reproduce
   
   1. Create an `InvocationChannel` and register an `InvocationContext` with a 
response future.
   2. Let the context become older than `channelExpiredInSeconds`.
   3. Run channel cleanup through `clearExpireContext()` or 
`ChannelManager.scanAndCleanChannels()`.
   4. Observe that the context is removed but the original response future is 
still not completed.
   
   ### What Did You Expect to See?
   
   When an invocation context is expired and removed by cleanup, its waiting 
response future should complete exceptionally with a timeout/cleanup error.
   
   ### What Did You See Instead?
   
   The invocation context is removed from the channel, but the response future 
remains pending forever.
   
   ### Additional Context
   
   This can leave local proxy callers hanging indefinitely on send/pop 
operations even after cleanup has already determined that the in-flight request 
expired.
   


-- 
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]

Reply via email to