uuuyuqi commented on issue #16270: URL: https://github.com/apache/dubbo/issues/16270#issuecomment-4448612993
**Real-world impact: an upstream gateway change unintentionally exposed this gap** A bit of background on why this came up — I want to share it because it shows the inconsistency is not just theoretical, and small upstream changes can flip many providers from "working" to "failing" overnight. In the deployment we operate, many internal services are exposed externally through an HTTP-to-Dubbo gateway. The gateway accepts JSON, builds the corresponding `Map<String, Object>` payload, and forwards the call to the backend Dubbo provider via `GenericService.$invoke`. Historically the gateway did **not** include the `class` entry in the forwarded Map. Recently the gateway rolled out a change to always include the `class` entry in the forwarded payload (a reasonable behavior for type fidelity in nested / polymorphic fields). Functionally for the typed-call path it would have been a no-op, but **on the Dubbo provider side it flipped many in-flight calls from the "no class key" branch (Serializable check skipped) to the "with class key" branch (Serializable check enforced via `loadClass`)**. The result was a wave of `IllegalArgumentException: ... has not implement Serializable interface` failures on providers whose DTOs had not yet been migrated to implement `Serializable`. The migration plan for those non-`Serializable` DTOs was already in flight on the security side (collect via runtime scan, drive remediation through tickets), so the long-term direction was understood. The surprise was that an upstream gateway change — a single line of "always add `class` for better type fidelity" — was enough to short-circuit that gradual migration and turn the gap into a production incident. This is why I think the inconsistency is worth fixing (or at least documenting clearly): the same DTO type behaving differently depending on whether a caller / gateway / proxy chose to include a `class` entry is **a hidden compatibility variable** that any change in middleware behavior can flip. If the framework itself enforced the contract consistently, this kind of upstream change would be a no-op rather than an outage trigger. -- 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]
