[
https://issues.apache.org/jira/browse/THRIFT-5802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868628#comment-17868628
]
Jens Geyer edited comment on THRIFT-5802 at 7/25/24 10:09 AM:
--------------------------------------------------------------
{quote}set: An unordered set of unique elements. Translates to an STL set, Java
HashSet, set in Python, etc. Note: PHP does not support sets, so it is treated
similar to a List
{quote}
So sending duplicated values is already incorrect. Hence, both Go and Py
respond in an equally valid manner. I would prefer Gos reaction but the input
data are illegal so the server can basically do whatever he wants - there is no
clear spec what should happen in such a case.
What IMHO indeed should be fixed is returning the incorrect data, as Node does.
[https://thrift.apache.org/docs/types]
was (Author: jensg):
{quote}
set: An unordered set of unique elements. Translates to an STL set, Java
HashSet, set in Python, etc. Note: PHP does not support sets, so it is treated
similar to a List
{quote}
So sending duplicated values is already incorrect. Hence, both Go and Py
respond in an equally valid manner. I would prefer Gos reaction but the input
data are illegal so the server can basically do whatever he wants. What IMHO
indeed should be fixed is returning the incorrect data, as Node does.
https://thrift.apache.org/docs/types
> Inconsistent Validation for transmitted values
> -----------------------------------------------
>
> Key: THRIFT-5802
> URL: https://issues.apache.org/jira/browse/THRIFT-5802
> Project: Thrift
> Issue Type: Bug
> Affects Versions: 0.19.0, 0.20.0
> Reporter: Team_RPCtester
> Priority: Major
>
> *Hi,*
> We discover an inconsistent behavior under V20.0 and V19.0 by the following
> example.
> The thrift file:
> {code:java}
> namespace java com.example
> namespace go commonResource
> service DataService {
> set<i8> Method_1(1: set<i8> agr_method_1)
> }
> {code}
> When using Go,Py3 and Node.js as the client side(writer) and Node.js as the
> server side(reader) with the protocol set to “json” and the transport set to
> “framed“. We sent the value [10, 43, 38, 38, -2]to the server, but the server
> received differently. The received are respectively nothing, [10, 43, 38, -2]
> and [10, 43, 38, 38, -2] from Go,Py3 and Node.js which is unexpected. Here
> is the relevant code:We use agr_method_1_0 as the parameter sent to the
> client side(writer).
> Go client side : It throws an error “[]int8 error writing set field: slice
> is not unique back”
> {code:java}
> set_item_0 := []int8 {10, 43, 38, 38, -2}
> re_1, err := dataserviceclient.Method_1(context.Background(),set_item_0)
> if err != nil {
> fmt.Println("Method_1 receives error ", err, " back")
> } else {
> fmt.Println("Method_1 receives ", re_1, " back")
> }
> {code}
> py3 client side
> {code:java}
> agr_method_1 = [10, 43, 38, 38, -2]
> try:
> re_1 = client.Method_1(agr_method_1)
> # re_1: [10, 43, 38, -2]
> except Exception as ex:
> print(f"Method_1 receives error {ex} back")
> {code}
> Nodejs client side
> {code:java}
> const arg_Method_1 = [10, 43, 38, 38, -2];
> console.log("Method_1 sends ", arg_Method_1, " end");
> try {
> const re_1 = await client.Method_1(arg_Method_1);
> console.log("Method_1 receives ", re_1, " back");
> //re_1 [10, 43, 38, 38, -2]
> } catch (error) {
> console.log("Method_1 receives error ", error, " back");
> }
> {code}
> Nodejs server:
> {code:java}
> Method_1: async function(agr_method_1, result) {
> console.log("Method_1 receives ", agr_method_1);
> result(null, agr_method_1);
> }
> {code}
> The Go client throws an error before transmitting the parameter, indicating
> that the items are not unique. The Node.js client transmits the duplicate
> values and receives duplicated values from the Node.js server. The Python
> client automatically de-duplicates the values and receives the de-duplicated
> values. This behavior is inconsistent across the different clients.
> Can you help check the issue?
> Thank you.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
