You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@dubbo.apache.org by "CuSO41108 (via GitHub)" <gi...@apache.org> on 2025/12/28 09:04:18 UTC
[PR] [Bug] Fix RpcContext compatibility between Object and String attachments [dubbo]
CuSO41108 opened a new pull request, #15934:
URL: https://github.com/apache/dubbo/pull/15934
…acy getAttachment API
## What is the purpose of the change?
This PR fixes the compatibility issue in `RpcContext` where non-String objects stored via `setObjectAttachment` could not be retrieved via the legacy `getAttachment(String)` method.
## Brief changelog
- Modified `RpcContext#setObjectAttachment` to automatically store a String representation of the object for legacy API compatibility.
- Addressed the TODO: "compatible with previous" in RpcContext.java.
## Verifying this change
I have added a unit test `RpcContextCompatibilityTest` to verify that:
1. `getObjectAttachment` returns the original object (e.g., Long).
2. `getAttachment` returns the String representation (e.g., "12345") instead of null.
I have already sent my ICLA to secretary@apache.org
## 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: notifications-unsubscribe@dubbo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org
Re: [PR] [Bug] Fix RpcContext compatibility between Object and String attachments [dubbo]
Posted by "codecov-commenter (via GitHub)" <gi...@apache.org>.
codecov-commenter commented on PR #15934:
URL: https://github.com/apache/dubbo/pull/15934#issuecomment-3694601277
## [Codecov](https://app.codecov.io/gh/apache/dubbo/pull/15934?dropdown=coverage&src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) Report
:x: Patch coverage is `0%` with `2 lines` in your changes missing coverage. Please review.
:white_check_mark: Project coverage is 32.11%. Comparing base ([`a3a35b5`](https://app.codecov.io/gh/apache/dubbo/commit/a3a35b5f8cb7d8bf8004f4fcc6063fbcaf945a96?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache)) to head ([`2404f50`](https://app.codecov.io/gh/apache/dubbo/commit/2404f50f074c0c0d59f39454238c146fcdc2ba37?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache)).
| [Files with missing lines](https://app.codecov.io/gh/apache/dubbo/pull/15934?dropdown=coverage&src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | Patch % | Lines |
|---|---|---|
| [...src/main/java/org/apache/dubbo/rpc/RpcContext.java](https://app.codecov.io/gh/apache/dubbo/pull/15934?src=pr&el=tree&filepath=dubbo-rpc%2Fdubbo-rpc-api%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fdubbo%2Frpc%2FRpcContext.java&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache#diff-ZHViYm8tcnBjL2R1YmJvLXJwYy1hcGkvc3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2R1YmJvL3JwYy9ScGNDb250ZXh0LmphdmE=) | 0.00% | [1 Missing and 1 partial :warning: ](https://app.codecov.io/gh/apache/dubbo/pull/15934?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) |
> :exclamation: There is a different number of reports uploaded between BASE (a3a35b5) and HEAD (2404f50). Click for more details.
>
> <details><summary>HEAD has 7 uploads less than BASE</summary>
>
>| Flag | BASE (a3a35b5) | HEAD (2404f50) |
>|------|------|------|
>|integration-tests-java8|1|0|
>|integration-tests-java21|1|0|
>|unit-tests-java8|1|0|
>|unit-tests-java25|1|0|
>|unit-tests-java11|1|0|
>|unit-tests-java17|1|0|
>|unit-tests-java21|1|0|
></details>
<details><summary>Additional details and impacted files</summary>
```diff
@@ Coverage Diff @@
## 3.3 #15934 +/- ##
=============================================
- Coverage 60.74% 32.11% -28.64%
+ Complexity 11702 10133 -1569
=============================================
Files 1938 1937 -1
Lines 88694 88674 -20
Branches 13387 13304 -83
=============================================
- Hits 53879 28474 -25405
- Misses 29291 56033 +26742
+ Partials 5524 4167 -1357
```
| [Flag](https://app.codecov.io/gh/apache/dubbo/pull/15934/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | Coverage Δ | |
|---|---|---|
| [integration-tests-java21](https://app.codecov.io/gh/apache/dubbo/pull/15934/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `?` | |
| [integration-tests-java8](https://app.codecov.io/gh/apache/dubbo/pull/15934/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `?` | |
| [samples-tests-java21](https://app.codecov.io/gh/apache/dubbo/pull/15934/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `32.05% <0.00%> (+0.02%)` | :arrow_up: |
| [samples-tests-java8](https://app.codecov.io/gh/apache/dubbo/pull/15934/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `29.73% <0.00%> (+0.04%)` | :arrow_up: |
| [unit-tests-java11](https://app.codecov.io/gh/apache/dubbo/pull/15934/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `?` | |
| [unit-tests-java17](https://app.codecov.io/gh/apache/dubbo/pull/15934/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `?` | |
| [unit-tests-java21](https://app.codecov.io/gh/apache/dubbo/pull/15934/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `?` | |
| [unit-tests-java25](https://app.codecov.io/gh/apache/dubbo/pull/15934/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `?` | |
| [unit-tests-java8](https://app.codecov.io/gh/apache/dubbo/pull/15934/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `?` | |
Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache#carryforward-flags-in-the-pull-request-comment) to find out more.
</details>
[:umbrella: View full report in Codecov by Sentry](https://app.codecov.io/gh/apache/dubbo/pull/15934?dropdown=coverage&src=pr&el=continue&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache).
:loudspeaker: Have feedback on the report? [Share it here](https://about.codecov.io/codecov-pr-comment-feedback/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache).
<details><summary> :rocket: New features to boost your workflow: </summary>
- :snowflake: [Test Analytics](https://docs.codecov.com/docs/test-analytics): Detect flaky tests, report on failures, and find test suite problems.
- :package: [JS Bundle Analysis](https://docs.codecov.com/docs/javascript-bundle-analysis): Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
</details>
--
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: notifications-unsubscribe@dubbo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org
Re: [PR] [Bug] Fix RpcContext compatibility between Object and String attachments [dubbo]
Posted by "CuSO41108 (via GitHub)" <gi...@apache.org>.
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: notifications-unsubscribe@dubbo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org
Re: [PR] [Bug] Fix RpcContext compatibility between Object and String attachments [dubbo]
Posted by "Copilot (via GitHub)" <gi...@apache.org>.
Copilot commented on code in PR #15934:
URL: https://github.com/apache/dubbo/pull/15934#discussion_r2649578102
##########
dubbo-rpc/dubbo-rpc-api/src/test/java/org/apache/dubbo/rpc/RpcContextCompatibilityTest.java:
##########
@@ -0,0 +1,51 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.dubbo.rpc;
+
+import java.util.Map;
+
+import org.junit.jupiter.api.Assertions;
+import org.junit.jupiter.api.Test;
+
+public class RpcContextCompatibilityTest {
+
+ @Test
+ void testAttachmentCompatibility() {
+ RpcContext context = RpcContext.getServiceContext();
+
+ String key = "test_long_key";
+ Long value = 12345L;
+ context.setObjectAttachment(key, value);
+
+ Assertions.assertEquals(value, context.getObjectAttachment(key));
+
+ Object legacyValue = context.getAttachment(key);
+ System.out.println("Legacy getAttachment result: " + legacyValue);
Review Comment:
The test uses System.out.println for debugging instead of proper assertions. The test should verify that the legacy getAttachment method returns the expected String value "12345" using an assertion like Assertions.assertEquals("12345", legacyValue) to ensure the compatibility fix is working correctly.
##########
dubbo-rpc/dubbo-rpc-api/src/test/java/org/apache/dubbo/rpc/RpcContextCompatibilityTest.java:
##########
@@ -0,0 +1,51 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.dubbo.rpc;
+
+import java.util.Map;
+
+import org.junit.jupiter.api.Assertions;
+import org.junit.jupiter.api.Test;
+
+public class RpcContextCompatibilityTest {
+
+ @Test
+ void testAttachmentCompatibility() {
+ RpcContext context = RpcContext.getServiceContext();
+
+ String key = "test_long_key";
+ Long value = 12345L;
+ context.setObjectAttachment(key, value);
+
+ Assertions.assertEquals(value, context.getObjectAttachment(key));
+
+ Object legacyValue = context.getAttachment(key);
+ System.out.println("Legacy getAttachment result: " + legacyValue);
+
+ Map<String, String> allAttachments = context.getAttachments();
+
+ try {
+ for (Map.Entry<String, String> entry : allAttachments.entrySet()) {
+ String k = entry.getKey();
+ String v = entry.getValue(); // 如果 entry.getValue() 实际是 Long，这里可能会崩
+ System.out.println(k + " = " + v);
+ }
+ } catch (ClassCastException e) {
+ System.err.println("发现不兼容 Bug！由于底层存了非 String 对象，导致老接口遍历崩溃: " + e.getMessage());
+ }
Review Comment:
The test relies on System.out.println instead of proper assertions. The try-catch block should assert that no ClassCastException occurs when iterating over attachments, and verify that the String representation exists in the map. Consider using Assertions.assertDoesNotThrow and validating the map contents.
##########
dubbo-rpc/dubbo-rpc-api/src/main/java/org/apache/dubbo/rpc/RpcContext.java:
##########
@@ -574,6 +574,9 @@ public RpcContext setAttachment(String key, Object value) {
public RpcContext setObjectAttachment(String key, Object value) {
// TODO compatible with previous
CLIENT_ATTACHMENT.get().setObjectAttachment(key, value);
+ if (value != null && !(value instanceof String)) {
+ CLIENT_ATTACHMENT.get().setAttachment(key, String.valueOf(value));
+ }
Review Comment:
This fix has a critical bug. When a non-String object is stored, the code first calls setObjectAttachment(key, value) which stores the object in the attachments map. Then it calls setAttachment(key, String.valueOf(value)), which delegates to setObjectAttachment and overwrites the original object with its String representation. This means getObjectAttachment(key) will return the String "12345" instead of the original Long object, breaking the intended behavior. The fix should store both representations without overwriting, or use a different storage mechanism.
--
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: notifications-unsubscribe@dubbo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org
Re: [PR] [Bug] Fix RpcContext compatibility between Object and String attachments [dubbo]
Posted by "RainYuY (via GitHub)" <gi...@apache.org>.
RainYuY commented on PR #15934:
URL: https://github.com/apache/dubbo/pull/15934#issuecomment-3713950471
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.
--
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: notifications-unsubscribe@dubbo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@dubbo.apache.org
For additional commands, e-mail: notifications-help@dubbo.apache.org