[client] Lookups for a leaderless bucket retry without backoff #4971

Search before asking

• I searched in the issues and found nothing similar.

Fluss version

1.0.0 (latest release)

Please describe the bug 🐞

Follow-up to #4959. When the client's metadata has no leader for a bucket, LookupSender.groupByLeaderAndType re-queues every lookup for that bucket with no delay. On each pass of the sender loop (about every 100 ms, set by client.lookup.batch-timeout), for every pending lookup the client:

• calls MetadataUpdater.leaderFor(), which makes up to 3 synchronous metadata requests on the single lookup sender thread;
• logs Failed to lookup the leader for ... when lookup at WARN with a full stack trace.

With N lookups pending for a leaderless bucket, each pass makes up to 3·N blocking metadata requests to the coordinator. Lookups for healthy buckets wait behind them. The retry backoff added in #4959 doesn't help here: these attempts skip the backoff and don't count as retries, so a lookup can loop like this until a leader appears.

This can happen when a bucket has no leader yet, for example during leader election in a rolling restart, or when the coordinator is unavailable.

Solution

1. Call leaderFor() once per bucket per pass, and reuse the result or failure for that bucket's other lookups.
2. Delay re-queued lookups with client.lookup.retry-backoff / -max, growing the delay with each attempt.
3. Keep today's behavior of not counting these attempts toward client.lookup.max-retries, so lookups don't start failing during routine restarts.
4. Log one WARN per bucket per pass, with the stack trace only at DEBUG.

Are you willing to submit a PR?

• I'm willing to submit a PR!