ban-xiu opened a new pull request, #16248:
URL: https://github.com/apache/dubbo/pull/16248
## What is the purpose of the change?
Problem
-----
In dual registration mode (register-mode=all) Dubbo emits a single
provider URL through two registries:
- interface-level -> registry:// (ZooKeeper, Nacos, ...)
- instance-level -> service-discovery-registry://
RegistryProtocol#export calls register() once; the registry wrapper
fans out to both arms. Any RuntimeException from the first arm aborts
the second, so a transient failure on the metadata center silently
takes down the interface-level registration that was otherwise healthy
(or vice versa). The pre-existing FrameworkStatusReportService only
reports a coarse "instance/interface" status and cannot tell observers
which arm failed, which swallowed the error, or why.
Fix
-----
1. FrameworkStatusReportService
- add reportRegistrationOutcome(mode, registryAddress, serviceKey,
success, errorMessage) + createRegistrationOutcomeReport() so each
registration attempt emits an independently tagged payload
{application, mode, registry, service, status, error?}.
2. RegistryProtocol
- new registerWithModeTag(registry, registryUrl, providerUrl) wraps
the existing register() call with per-arm failure isolation:
* success -> report SUCCESS tagged with the resolved mode
* RuntimeException:
- report FAILED with the cause message
- honor registryUrl check= parameter: rethrow iff check=true,
otherwise log a warn under CONFIG_REGISTER_INSTANCE_ERROR
(5-11) and return false so the sibling arm keeps going
- resolveRegisterModeTag() centralizes the INTERFACE_REGISTER vs
INSTANCE_REGISTER label (previously hardcoded in one log line).
- route export() and ExporterChangeableWrapper.register() through
the new wrapper; replace the hardcoded "[INSTANCE_REGISTER]" log
prefix with the resolved tag.
- reporting failures never leak into the registration flow
(wrapped in try/catch(Throwable)).
Tests
-----
- dubbo-common: FrameworkStatusReportServiceTest gains
testReportRegistrationOutcomeSuccess / Failure covering the new
payload shape.
- dubbo-registry-api: new RegistryProtocolDualRegisterTest with 4
reflection-driven cases over registerWithModeTag — success paths for
both protocols, check=true rethrow path, check=false swallow path.
A local CapturingFrameworkStatusReporter + SPI registration under
src/test/resources provides the capture sink (MockFrameworkStatus-
Reporter is scoped to dubbo-common tests and not reachable here).
Behavior change
-----
| Scenario | Before | After |
|---|---|---|
| Both arms succeed | 1 coarse `registration` report | 2 outcome reports,
one per mode, `status=SUCCESS` |
| One arm fails, `check=false` on that registry URL | exception bubbles
out, sibling arm may be skipped | failure is tagged + reported `FAILED`,
returns false,
sibling arm continues |
| One arm fails, `check=true` | exception bubbles out (no outcome report)
| outcome still reported `FAILED` **then** the original exception is rethrown |
| Reporter itself throws | would leak into registration flow | swallowed —
reporting never affects registration |
## Checklist
- [x] Make sure there is a
[GitHub_issue](https://github.com/apache/dubbo/issues) field for the change.
- [x] Write a pull request description that is detailed enough to understand
what the pull request does, how, and why.
- [x] Write necessary unit-test to verify your logic correction. If the new
feature or significant change is committed, please remember to add sample in
[dubbo samples](https://github.com/apache/dubbo-samples) project.
- [x] Make sure gitHub actions can pass. [Why the workflow is failing and
how to fix it?](../CONTRIBUTING.md)
--
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]
