Thanks — the isolation direction is right (bounded pool, per-destination in-flight guard, per-destination deadline, injectable sender). But the in-flight bookkeeping can permanently disable a destination, and I would rather fix that here than in a follow-up.

1. The in-flight flag is only cleared inside the task body, so anything that stops the task from running blocks that admin forever

serverInFlight is reset in the finally of the submitted runnable (:178-186). Two paths never reach it:

• Queued task cancelled at the deadline. poolSize is capped at MAX_BEAT_THREADS (8), so with more than eight destinations some submits sit in the queue. The deadline task (:187-195) calls future.cancel(true), and cancel on a FutureTask that has not started prevents it from ever running. Its finally never executes, the flag stays true, and every later beat to that admin is skipped with "still in flight" until the process restarts.
• Discarded submit. DiscardPolicy (:137) silently drops the command, yet AbstractExecutorService.submit still returns a FutureTask, so the caller gets a future that never completes and never clears the flag.

Concretely: ten admins, two of them slow, and those two stop receiving heartbeats permanently — the admin then marks those gateways offline. That is the opposite of the isolation this PR is about.

Minimal fix: also clear the flag in the timeout branch (AtomicBoolean.set(false) is idempotent, so double-clearing is harmless), or submit via CompletableFuture.runAsync(...).whenComplete((r, e) -> flag.set(false)), which runs on cancellation as well. And please replace DiscardPolicy with CallerRunsPolicy, or handle rejection explicitly — "silently dropped heartbeat + stuck flag" is the worst possible combination.

2. A malformed heartbeatTimeoutMs fails application start

:124 calls Long.parseLong(timeoutProp) in the constructor, and HeartbeatListenerConfiguration:47 builds this bean during startup. shenyu.bootstrap.heartBeat.props.heartbeatTimeoutMs=4s — an easy typo — throws NumberFormatException out of the constructor and takes the gateway down. Please parse defensively and fall back to DEFAULT_DEADLINE_MS with a warn, the same way the neighbouring blank check does.

3. Smaller things

• setBeatExecutor, setBeatSender, getBeatExecutor, getBeatSender are unused by main code and by the tests (which inject through the new constructor) — dead code, please drop them.
• Please add a test for the cancellation/rejection path. Every current test uses a generously sized pool, which is precisely why (1) is invisible to them.
• Worth stating in the PR body: deadlineMs <= 0 silently disables the deadline, and the 4 s deadline is only enforceable because RegisterUtils → OkHttpTools uses Okio timeouts that honour Thread.interrupted(). A custom BeatSender (the new extension point) must honour interrupts too, or the deadline becomes advisory.
• The branch has no CI run (no checks reported), so none of the new concurrency tests have executed in CI yet.

The overall shape is good; it is the "who clears the flag" question that needs to be closed before this goes in.

Approving the code. 2067420e addresses the three things I raised, and the third one is the interesting fix:

1. DiscardPolicy → AbortPolicy + catch. This was the real defect behind "heartbeats stop forever": with DiscardPolicy the task was silently dropped after the in-flight flag had been set, so finalInFlight stayed true and every later tick skipped that Admin. Resetting the flag in the rejection handler (and continue-ing to the next server) makes a saturated queue a dropped beat rather than a dead destination. Catching RejectedExecutionException is only possible because you switched the policy — with DiscardPolicy nothing is thrown, which is exactly why it was invisible.
2. Deadline cancellation resets the flag too. future.cancel(true) in the timeout task previously left the flag set until the worker's finally ran, and if the worker was stuck in a socket write that finally may be a long time coming. Resetting in the scheduled task as well closes that window; the double reset is harmless (AtomicBoolean.set(false) is idempotent).
3. parseDeadlineMs. A malformed heartbeatTimeoutMs used to throw out of the constructor and take down the whole listener; warn-and-default is the right behaviour for an optional tuning knob.

Also good: onShutdown now shuts down beatExecutor as well (it only handled the scheduler before, so the worker pool leaked a non-daemon-ish thread per listener on context close), and the test-only setters/getters are gone in favour of reflection in the test.

Non-blocking observations:

1. testMalformedHeartbeatTimeoutMsFallback feeds "4s" and asserts 4000L — which happens to equal DEFAULT_DEADLINE_MS, so at a glance the test reads as "4s is parsed to 4000 ms". It does prove the fallback (a NumberFormatException path is the only way to reach 4000 here), but "abc" or asserting the WARN would remove the ambiguity for the next reader.
2. future.cancel(true) interrupts the worker, but RegisterUtils.doHeartBeat runs over OkHttp, which does not abort an in-flight socket write on interrupt. So a "timed out" beat can still complete on the wire while the next tick has already been allowed to start — two concurrent heartbeats to the same Admin. That is still better than the previous no-deadline behaviour, but the isolation is not absolute; worth a comment so nobody assumes cancel(true) is a guarantee.
3. LOG.warn("Previous heartbeat to admin url :{} is still in flight, skipping.") fires on every tick while an Admin is slow. With a 3 s beat period and a hung Admin that is a lot of log volume; debug or a rate-limited warn would be kinder.
4. deadlineMs > 0 disables the deadline entirely, and parseDeadlineMs accepts negative values, so heartbeatTimeoutMs=-1 is a valid "off switch". That is a nice escape hatch — please mention it in the property documentation rather than leaving it to be discovered.

Two merge blockers, neither of them in the change itself:

• mergeStateStatus is DIRTY / mergeable: CONFLICTING. The branch conflicts with master (the heartbeat client was touched by other merged work). Please rebase.
• No CI has run on 2067420e. gh pr checks reports no checks on this head and actions/runs?head_sha=2067420e is empty, so the force-push did not start a workflow. After the rebase the push should trigger the normal set; if it does not, ask a maintainer to approve the run.

Re-review: #7762 [ISSUE #7743] Isolate destination heartbeats and enforce per-destination deadlines

Verdict: approved — both merge blockers are resolved, and the follow-up commit adopted three of my four non-blocking notes, including the one about cancel(true) not being a real guarantee.

Merge blockers resolved

• The branch no longer conflicts. mergeable_state went from DIRTY/CONFLICTING to BLOCKED, i.e. the rebase onto current master (including the heartbeat-client work that had landed) is clean.
• CI has now run on the rebased head. 22 checks pass, 9 are path-filtered skips, nothing failing. The previous head had no workflow run at all after the force-push, which is why I would not approve it then.

Non-blocking notes adopted

• cancel(true) is now documented as best-effort right where it matters:

  // Note: RegisterUtils.doHeartBeat relies on OkHttp. Thread interruption does not immediately
  // abort active socket writes on the wire, so cancel(true) is best-effort cancellation.

  That is the note I most wanted recorded. Without it, the next person reads future.cancel(true) and assumes the in-flight heartbeat is dead, when a "timed out" beat can still complete on the wire while the next tick starts — two concurrent beats to one Admin is now a bounded, understood state rather than a hidden one.
• The "still in flight" message moved from warn to debug. With a 5 s tick and a hung Admin, the previous level produced a warning per second per destination; debug keeps it available for diagnosis without flooding the log of a gateway that is otherwise working as designed.
• The <= 0 off-switch is documented rather than discoverable. parseDeadlineMs has a Javadoc stating "Values <= 0 (e.g. -1) disable the per-destination deadline entirely", so heartbeatTimeoutMs=-1 is a supported escape hatch instead of a curiosity.

The remaining note (the "4s" → 4000L assertion coinciding with DEFAULT_DEADLINE_MS) still stands as a readability nit; the "abc" case would make the fallback unambiguous.

What I re-verified in the current diff

• AbortPolicy plus the rejection handler is still the core fix, and still the right one: with the previous DiscardPolicy the task was dropped after inFlight had been set, so the destination was dead forever with no signal. Now RejectedExecutionException is caught, the flag is reset, and the loop continues to the next server — a saturated queue becomes a dropped beat, not a dead Admin.
• The flag is reset on all three paths: the worker's finally, the rejection handler, and the timeout task. The double reset is harmless because AtomicBoolean.set(false) is idempotent, and covering the timeout path matters because a worker stuck in a socket write may not reach its finally for a long time.
• inFlight is keyed per destination (Map<String, AtomicBoolean> via computeIfAbsent), so a slow Admin no longer blocks heartbeats to a healthy one. That is the "isolate destination heartbeats" half of the issue and it is done with the minimum state.
• poolSize = min(max(1, serverList.size()), 8) with a queue of serverList.size() bounds both concurrency and backlog by the actual destination count, so a large Admin list cannot spawn an unbounded pool. The MAX_BEAT_THREADS cap is the right guard.
• BeatSender is a genuine improvement, not just test plumbing. Extracting login/doHeartBeat behind an interface and defaulting to DefaultBeatSender removes the need for MockedStatic on RegisterUtils, which is what the old test did. A mockable seam on a network call is exactly where one belongs.
• onShutdown now tears down beatExecutor as well, with null guards on both executors and shutdownNow() only after the grace period. The previous version only shut the scheduler, so the worker pool leaked a thread per listener on context close.
• HeartbeatBoundPortTest sets heartbeatDirectExecution=true, so the port-binding test does not start a worker pool it never uses — that is the right use of the new escape hatch and shows it works as intended.

Non-blocking

• heartbeatDirectExecution reverts to inline execution on the scheduler thread, which also disables the per-destination inFlight isolation by setting serverInFlight = null. That is a deliberate coupling (an inline beat cannot overlap itself), but it means the property silently changes two things at once. Worth a sentence in the property documentation alongside the heartbeatTimeoutMs note.
• inFlight entries are never removed, including in onShutdown. Bounded by the destination count so it is not a leak, but inFlight.clear() in onShutdown would make the intent explicit.

CI is fully green on this head (22 pass, 0 fail), so this is mergeable as soon as a second reviewer agrees.