[fix][broker] Unthrottle producers immediately when publish rate limiting is disabled

[thetumbled]

Motivation

When publish rate limiting is disabled (for example by clearing the publish rate policy so update(null) is called), token buckets are nulled out immediately, but producers that were already throttled could remain blocked until a previously scheduled unthrottle task ran. That delayed task may have been scheduled with a very long wait time when the token bucket was deeply depleted, so disabling the limit in configuration did not restore traffic quickly. This change triggers the existing lock-free unthrottle path right away after disablement when an executor was already cached from a prior throttle on this limiter.

Modifications

• In PublishRateLimiterImpl, cache the ScheduledExecutorService used when scheduling unthrottleQueuedProducers after the first throttling event on this limiter instance.
• When update(PublishRate) is called with a null PublishRate (rate limiting disabled), call scheduleUnthrottling(cachedExecutor, 0) so queued producers are processed without waiting on the old delayed task.

Verifying this change

• Make sure that the change passes the CI checks.

(Please pick either of the following options)

This change is a trivial rework / code cleanup without any test coverage.

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR ensures producers are unthrottled immediately when publish rate limiting is disabled, avoiding long waits from previously scheduled delayed unthrottle tasks.

Changes:

• Cache the ScheduledExecutorService used for unthrottling after the first throttling event.
• When update(null) disables rate limiting, trigger unthrottling immediately (0 delay) using the cached executor.

[liangyepianzhou]

The scenario is valid, but the fix needs further evaluation. The root cause is that disabling rate limiting should **directly signal** throttled producers to be released, rather than waiting for the next scheduled cycle — i.e., the `disable` semantic itself should trigger an immediate (synchronous or async) unthrottle.

The current fix, via update(null), appears to work around the root cause by adding an operational workaround rather than addressing the underlying code defect. This may fail to resolve the fundamental issue, and worse, increases cognitive overhead for users who need to understand why an extra update(null) call is necessary.

Sorry, the code version I was looking at doesn't seem to be the latest.

[lhotari]

That delayed task may have been scheduled with a very long wait time when the token bucket was deeply depleted,

@thetumbled did the problem happen also with the fix in #25262 and #25269?

[thetumbled]

That delayed task may have been scheduled with a very long wait time when the token bucket was deeply depleted,

@thetumbled did the problem happen also with the fix in #25262 and #25269?

We haven't encountered this problem in our production environment yet. Since the bucket value is allowed to be negative, I am concerned that the producer may get stuck for a long time. We need a way to disable the throttling feature as quickly as possible.

[lhotari]

LGTM, a few comments to address.

[liangyepianzhou]

Maybe a test should be added to verify that the fix actually works. Otherwise, there's no way to fully confirm whether issues similar to #25502 (comment) still exist — the scope of manual review is always limited.

[thetumbled]

Maybe a test should be added to verify that the fix actually works. Otherwise, there's no way to fully confirm whether issues similar to #25502 (comment) still exist — the scope of manual review is always limited.

I will add one later.

[thetumbled]

Tests have been added. You can comment out the call to scheduleImmediateUnthrottling(); to verify the original behavior, and the test will output an error. @liangyepianzhou