“Connection refused ” caused by stopping tikv process when the tikv is marked as offline status

we mark a tikv as offline status by sending a pd api for delete the store, its a normal opreation as shrinking tikv nodes. Then, we kill the tikv process to simulate hardware damage, in a client which is start before shrinking operation, a scan api fail with print "gRPC api error: status: Unavailable, message: "error trying to connect: tcp connect error: Connection refused (os error 111)", details: [], metadata: MetadataMap { headers: {} }". But ,in a new start client, a same scan api can return correct result. Other way, when we start the tikv process again, the old client can return the correct result too.

Start by reproducing the reported sequence: mark a TiKV store offline through the PD API, stop the TiKV process, and compare scans from an existing client and a newly started client. The issue names no files or tests, so trace the client’s handling of store membership and connection errors. Done means the existing client handles this scenario consistently with a new client or the failure is clearly documented.