CuSO41108 commented on PR #15934: URL: https://github.com/apache/dubbo/pull/15934#issuecomment-3714802092
> I’m a bit concerned that this PR will alter the existing behavior. Additionally, it’s odd that when I set an Integer value as an attachment and retrieve it using getAttachment (instead of getStringAttachment), I end up getting a String. Hi @RainYuY, thank you for your feedback! Regarding your concern, this PR is specifically intended to address the `// TODO: compatible with previous` comment in `RpcContext.java`. Currently, the legacy `getAttachment(String key)` method returns `null` or may cause type conflicts when a non-String object is stored via the new `setObjectAttachment` API. This breaks backward compatibility for users who still rely on the legacy String-based API but interact with services using the newer Object-based attachments. By performing a "read-time conversion" in `getAttachment`: 1. **Backward Compatibility**: Legacy callers get a safe String representation instead of `null`. 2. **Type Safety**: The new `getObjectAttachment` still returns the original type (e.g., Integer/Long) without any loss of information, as the underlying storage remains untouched. 3. **Consistency**: It aligns the behavior of `getAttachment` with the existing `AttachmentsAdapter.ObjectToStringMap` logic. Do you think we should maintain the current behavior (returning null for non-String objects in the legacy API), or is this dynamic conversion a more robust way to fulfill the "compatible with previous" TODO? -- 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]
