Can one of the admins verify this patch?

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/28212/
Test FAILed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/28213/
Test PASSed.

What's the relationship to this PR btw? #9153

What's the relationship to this PR btw? #9153
I plan to split #9153 into three parts: the first is this pr, the second is support gcs client node resource subscribe idempotent, and the third is support gcs client object location subscribe idempotent.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/28437/
Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/28438/
Test PASSed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/28453/
Test FAILed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/28462/
Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Ray-PRB/28463/
Test PASSed.

Actor table idempotence is already implemented in #9449 and the node table should already be idempotent. I'm not familiar with what the job table does, but it looks like it's just marking jobs as dead, which is idempotent too.

So do we actually need this PR?

New changes in notification handlers could easily introduce bugs without being noticed. In GCS client to ensure message processing idempotent, we can develop more simple and efficient.

Actor table idempotence is already implemented in #9449 and the node table should already be idempotent. I'm not familiar with what the job table does, but it looks like it's just marking jobs as dead, which is idempotent too.
So do we actually need this PR?

New changes in notification handlers could easily introduce bugs without being noticed. In GCS client to ensure message processing idempotent, we can develop more simple and efficient.

But there is no point in making message processing in the GCS idempotent if the specific table logic is already idempotent. The problem has already been fixed, so this is just adding unnecessary complexity.

I'm not worried about changes in the notification handlers because these can be easily unit tested so we would definitely notice any new bugs. I suggest we close this PR.

Closing this PR for now since I don't believe the PR is necessary and it's now been 1 month. Feel free to reopen if there are more specific changes that need to be made.