AlexStocks opened a new pull request, #3578:
URL: https://github.com/apache/dubbo-go/pull/3578
## What problem does this PR solve?
This aligns dubbo-go v3.3's metadata `revision` computation with Java Dubbo
3.3 so the two sides produce **byte-for-byte identical** revision strings.
Previously dubbo-go computed `revision` with **SHA-512** and a
pipe-separated `toDescString`, while Java used **MD5** with a different string
format. The mismatched revision caused a Consumer to cache the same service's
metadata **twice** (one Go copy + one Java copy) under `metadataCacheKey(app,
registryId, revision)`. Interop still worked, but metadata efficiency was lost.
Fixes #3577
## Root cause & fix (3 inconsistencies resolved)
1. **Hash algorithm**: SHA-512 → MD5 (32-char lowercase hex), matching
`RevisionResolver.calRevision()` in Java.
2. **`toDescString` serialization**: changed from
`name|group|version|protocol|port|path|params|methods` to the Java form
`getMatchKey() + port + path + TreeMap(params).toString()` — i.e. `matchKey +
strconv.Itoa(port) + path + "{k=v, k=v}"` (no separators, methods excluded).
`matchKey = serviceKey + ":" + protocol` was already identical to Java and is
unchanged.
3. **`methods` participation**: Java excludes the method list from the
revision string. Added a `ServiceInfo.Methods []string` field (hessian/json
tagged `methods`); `NewServiceInfoWithURL` stops writing `MethodsKey` into
params and sets `si.Methods` instead. `GetMethods()` / `DeepCopy()` updated;
`GetParams()` no longer injects methods.
## Verification
- Golden vector derived **independently from the Java spec** (not from Go
output): `app + sorted-by-matchKey toDescString(...)` → MD5
`8ab6351c86cccf642be0a2cda8be847a`, matching Java.
- Tests: `go test ./metadata/info/... ./registry/servicediscovery/...` →
**all pass** (73 test cases). Includes hessian serialization of `ServiceInfo`,
`toDescString` format locks, Java-alignment golden test, empty-services →
`"0"`, ordering independence, and method-list exclusion.
- Multi-service ordering matches Java: the `services` map is keyed by
`matchKey` and sorted by it (same as Java's TreeMap).
## Out of scope (known residual difference)
- The `protocol`-empty `:` edge case in `common.MatchKey` is **not** changed
this round — service-discovery URLs always carry a protocol, and the change has
too-wide impact. Documented as a follow-up.
## Test plan
- [x] `go test ./metadata/info/...`
- [x] `go test ./registry/servicediscovery/...`
--
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]
