[Client] Fix LookupSender doesn't update bucket metadata when receive NotLeaderOrFollowerException in bucket level

[swuferhong]

Purpose

Linked issue: close #1927

This pr is aims to fix LookupSender doesn't update bucket metadata when receive NotLeaderOrFollowerException in bucket level

Brief change log

Tests

API and Format

Documentation

[loserwang1024]

I have left a comment.

[loserwang1024]

The code is same as LogFetcher, can we extract this same code in protected class? If some problem occurs, we only need to change once.

[swuferhong]

The code is same as LogFetcher, can we extract this same code in protected class? If some problem occurs, we only need to change once.

@wuchong will refactor the client metadata code implement, so there is no need to uniform. It's sufficient to have test coverage.

[luoyuxia]

Seems "// todo: try to get value when get is re-triable in FLUSS-56857409" can be finished with this pr?

[swuferhong]

Seems "// todo: try to get value when get is re-triable in FLUSS-56857409" can be finished with this pr?

This PR may not be able to fix the issue. Only when the LookupSender introduces a retry mechanism can the lookup produce deterministic results. In the current implementation, the lookup will still throw errors, and retries must be handled at the upper layer (flink).

[swuferhong]

Seems "// todo: try to get value when get is re-triable in FLUSS-56857409" can be finished with this pr?

Hi, @platinumhamburg. Your PR #1915 has already addressed this issue. Could you please remove this todo comment in your PR and improve the tests accordingly?

[platinumhamburg]

Seems "// todo: try to get value when get is re-triable in FLUSS-56857409" can be finished with this pr?

Hi, @platinumhamburg. Your PR #1915 has already addressed this issue. Could you please remove this todo comment in your PR and improve the tests accordingly?

I thought about it, and PR #1915 currently does not implement infinite retries nor support delayed backoff retries. In fact, even with limited retries, a single lookup does not guarantee the "deterministic" result expected here, so this TODO item should not be removed in PR #1915.

[loserwang1024]

LGTM