AryamannSingh7 commented on PR #16356:
URL: https://github.com/apache/dubbo/pull/16356#issuecomment-4928458524

   Hi @zrlw — following up here since you were tagged on this one.
   
   Quick summary of why this matters: under a multi-registry setup where one 
registry is weakly dependent (`check=false`) and unavailable at startup, the 
application fails to boot with an NPE rather than degrading gracefully — which 
is the entire point of `check=false`. It's a regression: `3.2.0`–`3.2.4` start 
fine, `3.2.5`+ do not, and it reproduces on `3.3.x`.
   
   The cause is that `AbstractRegistryFactory#getRegistry` returns `null` under 
`check=false` when the registry can't be created, and `RegistryFactoryWrapper` 
wraps that `null` into a `ListenerRegistryWrapper`. A null delegate is 
therefore an expected state — `register` / `unregister` / `subscribe` already 
guard for it — but `getUrl` / `isAvailable` / `destroy` / `unsubscribe` / 
`isServiceDiscovery` / `lookup` were never guarded. Separately, 
`RegistryDirectory#subscribe` calls `registry.getUrl().getParameter(...)` 
unconditionally for the metrics cluster name; that line came in with #12582, 
released in `3.2.5`, which is exactly where the regression starts.
   
   The change just completes the null-safety that was already half-present, and 
guards the metrics lookup. There's no behaviour change when the registry is 
non-null. `ListenerRegistryWrapperTest#testNullRegistryIsTolerated` reproduces 
the NPE without the fix and passes with it; `:dubbo-registry-api` tests and 
`spotless:check` are green locally on JDK 21.
   
   The branch is now rebased onto current `3.3`, so CI should be running clean. 
Happy to adjust the approach if you'd prefer the guard live somewhere else 
(e.g. in `RegistryFactoryWrapper`, by not wrapping a null registry at all). 
Would appreciate a look when you have time. Thanks!
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to