Qiao-yq opened a new pull request, #3370: URL: https://github.com/apache/dubbo-go/pull/3370
### Description Fixes #3350 ### Summary Replace the CRC32-based revision calculation with a canonical MD5-based approach aligned with Java dubbo's `MetadataInfo.calAndGetRevision()`. The existing `resolveRevision` builds revision from a few raw URL fields (`app + path + version + port + method`) and sums CRC32 values — missing `group`, `protocol`, and `params` (`timeout/loadbalance/cluster/serialization`, etc.), with weak collision resistance and no binding to the actual serialized metadata content. ### Changes **`metadata/info/metadata_info.go`** Three new methods: - `ServiceInfo.toDescString()` — deterministic string representation in format `name|group|version|protocol|port|path|params|methods`, with sorted params keys and sorted methods for stable output. - `CalRevision(app, services)` — computes MD5 hex digest from `app` concatenated with sorted `ServiceInfo.toDescString()` outputs. Returns `"0"` for empty services (matches Java `EMPTY_REVISION`). - `MetadataInfo.CalAndGetRevision()` — updates `info.Revision` in-place from its own canonical services map. **`registry/servicediscovery/customizer/service_revision_customizer.go`** - `resolveRevision` — rewrites the core logic: instead of CRC32‑summing `app+path+version+port+method`, it converts each URL to a canonical `ServiceInfo` via `NewServiceInfoWithURL`, groups by `MatchKey`, and delegates to `info.CalRevision`. - URL source — customizers now obtain URLs from `instance.GetServiceMetadata()` (instance‑scoped) rather than `GetMetadataService().GetExportedServiceURLs()` (global aggregation). Each instance's revision now correctly reflects only its own app's metadata, matching Java's `this.services` semantics. **`registry/servicediscovery/customizer/service_revision_customizer_test.go` (new)** 10 test cases covering: `group`/`protocol`/`params`/`methods`/`version` change detection, deterministic output, empty input, URL ordering independence, param key ordering independence, and non‑`IncludeKeys` filtering. ### Compatibility - **Revision algorithm change** is a one‑time switch on upgrade — all providers compute new revision values on first startup. - **Provider:** new revision is published to the remote metadata center, naturally overwriting the old entry (revision is the storage key). No manual migration needed. - **Consumer:** cached revision no longer matches after provider upgrade → cache miss at remote → transparent fallback to fetching latest `MetadataInfo` from the provider instance directly. Cached under new revision for subsequent calls. - **Rolling upgrade:** old providers keep publishing old‑style revisions alongside new ones. Consumer caches both independently. Phases out as old providers are decommissioned. - Revision is a cache signal, **not persistent state** — no data migration or config changes required. ### Checklist - [x] I confirm the target branch is `develop` - [x] Code has passed local testing - [x] I have added tests that prove my fix is effective or that my feature works -- 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]
