[SiriusTL666]

Follow-up to #16542, covering the two non-blocking points from the review.

1. The probe gets its own timeout option

The probe read the registry url's generic timeout, which defaults to 1000 ms and also governs unrelated registry operations such as listener.wait. Sharing one parameter means the two cannot be tuned independently: raising timeout to give the probe more slack also changes how long other registry operations wait, and lowering it for something else silently tightens the probe.

The probe now reads clean.check.timeout on the registry url (not the provider url — the budget belongs to the registry doing the cleaning), defaulting to the same 1000 ms. Existing deployments behave exactly as they do after #16542, so this is a separable improvement rather than a behaviour change.

2. The regression test no longer depends on the network

You were right that the timing test was weak. Asserting elapsed time against TEST-NET-1 passes without the timeout wherever the connect fails immediately — no route to host, or a firewall that rejects rather than drops — so in those environments it proved nothing. That is the general failure mode of timing assertions, not just this one.

The test now captures the constructed Socket and asserts the exact value passed to connect(), which is platform independent. I verified it actually catches the regression: switching back to the shared timeout key makes it fail. The interrupt test is mocked the same way, so it no longer depends on routing either.

There are now three cases: the configured value reaches connect(), the default applies when nothing is configured, and a provider that accepts connections is not expired.

3. The slow-provider trade-off, documented in code

Point (1) in your review — a provider that accepts more slowly than the budget is now treated as expired and unregistered — is the intended semantics of a liveness probe, but it was only recorded in the review thread. It is now in the field javadoc, where the next person to touch this will see it.

Verification

JDK 17, dubbo-registry-multicast: 18/18 pass (MulticastRegistryTest 17, MulticastRegistryFactoryTest 1). spotless:apply clean.

Reverse-verified: with the shared timeout key restored, testLivenessProbePassesTheConfiguredTimeoutToConnect fails with the actual argument 1000 instead of 250.

I kept this separate from #16542 rather than reopening it, since that change is already merged and this one is independently reviewable. Happy to fold it into a different shape if you prefer.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 60.95%. Comparing base (7152ee9) to head (7e7607e).

Additional details and impacted files

@@             Coverage Diff              @@
##                3.3   #16552      +/-   ##
============================================
+ Coverage     59.87%   60.95%   +1.07%     
- Complexity    11745    11763      +18     
============================================
  Files          1953     1953              
  Lines         89259    89278      +19     
  Branches      13393    13475      +82     
============================================
+ Hits          53446    54420     +974     
+ Misses        30282    29271    -1011     
- Partials       5531     5587      +56     

Flag	Coverage Δ
integration-tests-java21	32.07% <0.00%> (ø)
integration-tests-java8	32.21% <0.00%> (+<0.01%)	⬆️
samples-tests-java21	32.12% <100.00%> (+<0.01%)	⬆️
samples-tests-java8	29.78% <0.00%> (+0.02%)	⬆️
unit-tests-java11	59.16% <100.00%> (-0.03%)	⬇️
unit-tests-java17	58.68% <100.00%> (?)
unit-tests-java21	58.68% <100.00%> (?)
unit-tests-java25	58.62% <100.00%> (?)
unit-tests-java8	59.20% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.