[jira] [Commented] (THRIFT-4661) Rust enum name wrong case in generated structs
[
https://issues.apache.org/jira/browse/THRIFT-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16677827#comment-16677827
]
ASF GitHub Bot commented on THRIFT-4661:
jake-ruyi opened a new pull request #1623: THRIFT-4661: Rust enum name wrong
case in generated structs
URL: https://github.com/apache/thrift/pull/1623
Client: rs
Small fix with test.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Rust enum name wrong case in generated structs
> --
>
> Key: THRIFT-4661
> URL: https://issues.apache.org/jira/browse/THRIFT-4661
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Compiler
>Affects Versions: 0.11.0
> Environment: C:\Users\jake>rustup show
> Default host: x86_64-pc-windows-msvc
> stable-x86_64-pc-windows-msvc (default)
> rustc 1.30.0 (da5f414c2 2018-10-24)
>Reporter: J W
>Priority: Major
>
> *For this thrift (note lowercase "e" at beginning of enum name):*
> enum ePlatform
> { None = 0 }
> struct SettingItem
> { 1: ePlatform platform }
> *Generated with:*
> thrift -gen rs -out ../rust/thrift/src enum_lowercase_prefix.thrift
> *Generated Rust fails to compile:*
> error[E0412]: cannot find type `ePlatform` in this scope
> --> src\enum_lowercase_prefix.rs:71:24
>
> 71 | pub platform: Option,
> |^ did you mean `EPlatform`?|
>
> *In t_rs_generator.cc line 3025:*
> return rust_namespace(ttype) + ttype->get_name();
> *To match behavior in generate_enum(), probably needs to be:*
> return rust_namespace(ttype) + rust_camel_case(ttype->get_name());
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4662) Rust const string calls function at compile time
[ https://issues.apache.org/jira/browse/THRIFT-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16677894#comment-16677894 ] ASF GitHub Bot commented on THRIFT-4662: jake-ruyi opened a new pull request #1624: THRIFT-4662: Rust const string calls function at compile time URL: https://github.com/apache/thrift/pull/1624 Client: rs Fix with simple test This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Rust const string calls function at compile time > > > Key: THRIFT-4662 > URL: https://issues.apache.org/jira/browse/THRIFT-4662 > Project: Thrift > Issue Type: Bug > Components: Rust - Compiler >Affects Versions: 0.11.0 > Environment: C:\Users\jake>rustup show > Default host: x86_64-pc-windows-msvc > stable-x86_64-pc-windows-msvc (default) > rustc 1.30.0 (da5f414c2 2018-10-24) >Reporter: J W >Priority: Major > > *For this thrift:* > const string broker_playback_message = "mmi.developer.playback" > *Generates:* > // thrift -gen rs -out ../rust/thrift/src const_string.thrift > pub const BROKER_PLAYBACK_MESSAGE: String = > "mmi.developer.playback".to_owned(); > *Fails to compile:* > error[E0015]: calls in constants are limited to tuple structs and tuple > variants > note: a limited form of compile-time function evaluation is available on a > nightly compiler via `const fn` > *Fix:* > Probably want to output: > pub const BROKER_PLAYBACK_MESSAGE: &str = "mmi.developer.playback"; > > Looking at render_const_value() it looks like byte arrays will have the same > issue. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-4662) Rust const string calls function at compile time
[ https://issues.apache.org/jira/browse/THRIFT-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16677895#comment-16677895 ] J W commented on THRIFT-4662: - Created PR: https://github.com/apache/thrift/pull/1624 > Rust const string calls function at compile time > > > Key: THRIFT-4662 > URL: https://issues.apache.org/jira/browse/THRIFT-4662 > Project: Thrift > Issue Type: Bug > Components: Rust - Compiler >Affects Versions: 0.11.0 > Environment: C:\Users\jake>rustup show > Default host: x86_64-pc-windows-msvc > stable-x86_64-pc-windows-msvc (default) > rustc 1.30.0 (da5f414c2 2018-10-24) >Reporter: J W >Priority: Major > > *For this thrift:* > const string broker_playback_message = "mmi.developer.playback" > *Generates:* > // thrift -gen rs -out ../rust/thrift/src const_string.thrift > pub const BROKER_PLAYBACK_MESSAGE: String = > "mmi.developer.playback".to_owned(); > *Fails to compile:* > error[E0015]: calls in constants are limited to tuple structs and tuple > variants > note: a limited form of compile-time function evaluation is available on a > nightly compiler via `const fn` > *Fix:* > Probably want to output: > pub const BROKER_PLAYBACK_MESSAGE: &str = "mmi.developer.playback"; > > Looking at render_const_value() it looks like byte arrays will have the same > issue. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (THRIFT-4662) Rust const string calls function at compile time
[ https://issues.apache.org/jira/browse/THRIFT-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J W updated THRIFT-4662: Comment: was deleted (was: Created PR: https://github.com/apache/thrift/pull/1624) > Rust const string calls function at compile time > > > Key: THRIFT-4662 > URL: https://issues.apache.org/jira/browse/THRIFT-4662 > Project: Thrift > Issue Type: Bug > Components: Rust - Compiler >Affects Versions: 0.11.0 > Environment: C:\Users\jake>rustup show > Default host: x86_64-pc-windows-msvc > stable-x86_64-pc-windows-msvc (default) > rustc 1.30.0 (da5f414c2 2018-10-24) >Reporter: J W >Priority: Major > > *For this thrift:* > const string broker_playback_message = "mmi.developer.playback" > *Generates:* > // thrift -gen rs -out ../rust/thrift/src const_string.thrift > pub const BROKER_PLAYBACK_MESSAGE: String = > "mmi.developer.playback".to_owned(); > *Fails to compile:* > error[E0015]: calls in constants are limited to tuple structs and tuple > variants > note: a limited form of compile-time function evaluation is available on a > nightly compiler via `const fn` > *Fix:* > Probably want to output: > pub const BROKER_PLAYBACK_MESSAGE: &str = "mmi.developer.playback"; > > Looking at render_const_value() it looks like byte arrays will have the same > issue. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-4529) Rust generation should include #![allow(non_snake_case)] or force conform to Rust style guidelines
[
https://issues.apache.org/jira/browse/THRIFT-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16678088#comment-16678088
]
Allen George commented on THRIFT-4529:
--
I'm sorry I missed this :/ Does this happen only for enum variants?
> Rust generation should include #![allow(non_snake_case)] or force conform to
> Rust style guidelines
> --
>
> Key: THRIFT-4529
> URL: https://issues.apache.org/jira/browse/THRIFT-4529
> Project: Thrift
> Issue Type: Improvement
> Components: Rust - Compiler
>Affects Versions: 0.11.0
>Reporter: Joshua
>Priority: Minor
>
> Without this, building a project using a thrift file meant for multiple
> languages may end up with many compiler warnings similar to the following:
> {code:sh}
> warning: variant `EXAMPLE_NAME` should have a camel case name such as
> `ExampleName`
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4661) Rust enum name wrong case in generated structs
[
https://issues.apache.org/jira/browse/THRIFT-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16678107#comment-16678107
]
ASF GitHub Bot commented on THRIFT-4661:
allengeorge commented on issue #1623: THRIFT-4661: Rust enum name wrong case in
generated structs
URL: https://github.com/apache/thrift/pull/1623#issuecomment-436599340
@jake-ruyi Thank you for the bug report and the PR! The changes look good.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Rust enum name wrong case in generated structs
> --
>
> Key: THRIFT-4661
> URL: https://issues.apache.org/jira/browse/THRIFT-4661
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Compiler
>Affects Versions: 0.11.0
> Environment: C:\Users\jake>rustup show
> Default host: x86_64-pc-windows-msvc
> stable-x86_64-pc-windows-msvc (default)
> rustc 1.30.0 (da5f414c2 2018-10-24)
>Reporter: J W
>Priority: Major
>
> *For this thrift (note lowercase "e" at beginning of enum name):*
> enum ePlatform
> { None = 0 }
> struct SettingItem
> { 1: ePlatform platform }
> *Generated with:*
> thrift -gen rs -out ../rust/thrift/src enum_lowercase_prefix.thrift
> *Generated Rust fails to compile:*
> error[E0412]: cannot find type `ePlatform` in this scope
> --> src\enum_lowercase_prefix.rs:71:24
>
> 71 | pub platform: Option,
> |^ did you mean `EPlatform`?|
>
> *In t_rs_generator.cc line 3025:*
> return rust_namespace(ttype) + ttype->get_name();
> *To match behavior in generate_enum(), probably needs to be:*
> return rust_namespace(ttype) + rust_camel_case(ttype->get_name());
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4661) Rust enum name wrong case in generated structs
[
https://issues.apache.org/jira/browse/THRIFT-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16678112#comment-16678112
]
ASF GitHub Bot commented on THRIFT-4661:
allengeorge commented on issue #1623: THRIFT-4661: Rust enum name wrong case in
generated structs
URL: https://github.com/apache/thrift/pull/1623#issuecomment-436599745
@jeking3 The build failures appear to be unrelated.
On Appveyor it looks like JDK8 could not be downloaded/unpackaged (?) and on
Travis it looks like the CL compile failed because it couldn't find a generated
thrift file (I wonder if there's some sort of Makefile bug or race; lemme look
into that).
Could this be merged?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Rust enum name wrong case in generated structs
> --
>
> Key: THRIFT-4661
> URL: https://issues.apache.org/jira/browse/THRIFT-4661
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Compiler
>Affects Versions: 0.11.0
> Environment: C:\Users\jake>rustup show
> Default host: x86_64-pc-windows-msvc
> stable-x86_64-pc-windows-msvc (default)
> rustc 1.30.0 (da5f414c2 2018-10-24)
>Reporter: J W
>Priority: Major
>
> *For this thrift (note lowercase "e" at beginning of enum name):*
> enum ePlatform
> { None = 0 }
> struct SettingItem
> { 1: ePlatform platform }
> *Generated with:*
> thrift -gen rs -out ../rust/thrift/src enum_lowercase_prefix.thrift
> *Generated Rust fails to compile:*
> error[E0412]: cannot find type `ePlatform` in this scope
> --> src\enum_lowercase_prefix.rs:71:24
>
> 71 | pub platform: Option,
> |^ did you mean `EPlatform`?|
>
> *In t_rs_generator.cc line 3025:*
> return rust_namespace(ttype) + ttype->get_name();
> *To match behavior in generate_enum(), probably needs to be:*
> return rust_namespace(ttype) + rust_camel_case(ttype->get_name());
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4529) Rust generation should include #![allow(non_snake_case)] or force conform to Rust style guidelines
[
https://issues.apache.org/jira/browse/THRIFT-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16678114#comment-16678114
]
Allen George commented on THRIFT-4529:
--
Looks like it. For some reason I totally missed the variant section in [Naming
Conventions|https://doc.rust-lang.org/1.0.0/style/style/naming/README.html]. It
looks like a very simple fix.
> Rust generation should include #![allow(non_snake_case)] or force conform to
> Rust style guidelines
> --
>
> Key: THRIFT-4529
> URL: https://issues.apache.org/jira/browse/THRIFT-4529
> Project: Thrift
> Issue Type: Improvement
> Components: Rust - Compiler
>Affects Versions: 0.11.0
>Reporter: Joshua
>Priority: Minor
>
> Without this, building a project using a thrift file meant for multiple
> languages may end up with many compiler warnings similar to the following:
> {code:sh}
> warning: variant `EXAMPLE_NAME` should have a camel case name such as
> `ExampleName`
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4529) Rust generation should include #![allow(non_snake_case)] or force conform to Rust style guidelines
[
https://issues.apache.org/jira/browse/THRIFT-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16678115#comment-16678115
]
Allen George commented on THRIFT-4529:
--
Looks like it. For some reason I totally missed the variant section in [Naming
Conventions|https://doc.rust-lang.org/1.0.0/style/style/naming/README.html]. It
looks like a very simple fix.
> Rust generation should include #![allow(non_snake_case)] or force conform to
> Rust style guidelines
> --
>
> Key: THRIFT-4529
> URL: https://issues.apache.org/jira/browse/THRIFT-4529
> Project: Thrift
> Issue Type: Improvement
> Components: Rust - Compiler
>Affects Versions: 0.11.0
>Reporter: Joshua
>Priority: Minor
>
> Without this, building a project using a thrift file meant for multiple
> languages may end up with many compiler warnings similar to the following:
> {code:sh}
> warning: variant `EXAMPLE_NAME` should have a camel case name such as
> `ExampleName`
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (THRIFT-4662) Rust const string calls function at compile time
[ https://issues.apache.org/jira/browse/THRIFT-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen George reassigned THRIFT-4662: Assignee: Allen George > Rust const string calls function at compile time > > > Key: THRIFT-4662 > URL: https://issues.apache.org/jira/browse/THRIFT-4662 > Project: Thrift > Issue Type: Bug > Components: Rust - Compiler >Affects Versions: 0.11.0 > Environment: C:\Users\jake>rustup show > Default host: x86_64-pc-windows-msvc > stable-x86_64-pc-windows-msvc (default) > rustc 1.30.0 (da5f414c2 2018-10-24) >Reporter: J W >Assignee: Allen George >Priority: Major > > *For this thrift:* > const string broker_playback_message = "mmi.developer.playback" > *Generates:* > // thrift -gen rs -out ../rust/thrift/src const_string.thrift > pub const BROKER_PLAYBACK_MESSAGE: String = > "mmi.developer.playback".to_owned(); > *Fails to compile:* > error[E0015]: calls in constants are limited to tuple structs and tuple > variants > note: a limited form of compile-time function evaluation is available on a > nightly compiler via `const fn` > *Fix:* > Probably want to output: > pub const BROKER_PLAYBACK_MESSAGE: &str = "mmi.developer.playback"; > > Looking at render_const_value() it looks like byte arrays will have the same > issue. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (THRIFT-4529) Rust generation should include #![allow(non_snake_case)] or force conform to Rust style guidelines
[
https://issues.apache.org/jira/browse/THRIFT-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Allen George reassigned THRIFT-4529:
Assignee: Allen George
> Rust generation should include #![allow(non_snake_case)] or force conform to
> Rust style guidelines
> --
>
> Key: THRIFT-4529
> URL: https://issues.apache.org/jira/browse/THRIFT-4529
> Project: Thrift
> Issue Type: Improvement
> Components: Rust - Compiler
>Affects Versions: 0.11.0
>Reporter: Joshua
>Assignee: Allen George
>Priority: Minor
>
> Without this, building a project using a thrift file meant for multiple
> languages may end up with many compiler warnings similar to the following:
> {code:sh}
> warning: variant `EXAMPLE_NAME` should have a camel case name such as
> `ExampleName`
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (THRIFT-4661) Rust enum name wrong case in generated structs
[
https://issues.apache.org/jira/browse/THRIFT-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Allen George reassigned THRIFT-4661:
Assignee: Allen George
> Rust enum name wrong case in generated structs
> --
>
> Key: THRIFT-4661
> URL: https://issues.apache.org/jira/browse/THRIFT-4661
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Compiler
>Affects Versions: 0.11.0
> Environment: C:\Users\jake>rustup show
> Default host: x86_64-pc-windows-msvc
> stable-x86_64-pc-windows-msvc (default)
> rustc 1.30.0 (da5f414c2 2018-10-24)
>Reporter: J W
>Assignee: Allen George
>Priority: Major
>
> *For this thrift (note lowercase "e" at beginning of enum name):*
> enum ePlatform
> { None = 0 }
> struct SettingItem
> { 1: ePlatform platform }
> *Generated with:*
> thrift -gen rs -out ../rust/thrift/src enum_lowercase_prefix.thrift
> *Generated Rust fails to compile:*
> error[E0412]: cannot find type `ePlatform` in this scope
> --> src\enum_lowercase_prefix.rs:71:24
>
> 71 | pub platform: Option,
> |^ did you mean `EPlatform`?|
>
> *In t_rs_generator.cc line 3025:*
> return rust_namespace(ttype) + ttype->get_name();
> *To match behavior in generate_enum(), probably needs to be:*
> return rust_namespace(ttype) + rust_camel_case(ttype->get_name());
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (THRIFT-4529) Rust generation should include #![allow(non_snake_case)] or force conform to Rust style guidelines
[
https://issues.apache.org/jira/browse/THRIFT-4529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Allen George updated THRIFT-4529:
-
Comment: was deleted
(was: Looks like it. For some reason I totally missed the variant section in
[Naming
Conventions|https://doc.rust-lang.org/1.0.0/style/style/naming/README.html]. It
looks like a very simple fix.)
> Rust generation should include #![allow(non_snake_case)] or force conform to
> Rust style guidelines
> --
>
> Key: THRIFT-4529
> URL: https://issues.apache.org/jira/browse/THRIFT-4529
> Project: Thrift
> Issue Type: Improvement
> Components: Rust - Compiler
>Affects Versions: 0.11.0
>Reporter: Joshua
>Priority: Minor
>
> Without this, building a project using a thrift file meant for multiple
> languages may end up with many compiler warnings similar to the following:
> {code:sh}
> warning: variant `EXAMPLE_NAME` should have a camel case name such as
> `ExampleName`
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Can changes for the 0.12.0 compiler still be submitted?
Hi all - I’d like to cherry-pick a couple of PRs for the rust generator to the 0.12.0 branch. I know a message was sent about the branch being cut. Has packaging started yet? That is, is it too late for these generator changes to make it in for 0.12.0? Thanks, Allen
[jira] [Commented] (THRIFT-4662) Rust const string calls function at compile time
[
https://issues.apache.org/jira/browse/THRIFT-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16678210#comment-16678210
]
ASF GitHub Bot commented on THRIFT-4662:
allengeorge commented on a change in pull request #1624: THRIFT-4662: Rust
const string calls function at compile time
URL: https://github.com/apache/thrift/pull/1624#discussion_r231499393
##
File path: compiler/cpp/src/thrift/generate/t_rs_generator.cc
##
@@ -673,15 +676,22 @@ void t_rs_generator::render_const_value_holder(const
string& name, t_type* ttype
f_gen_ << endl;
}
-void t_rs_generator::render_const_value(t_type* ttype, t_const_value* tvalue) {
+void t_rs_generator::render_const_value(t_type* ttype, t_const_value* tvalue,
bool isowned) {
if (ttype->is_base_type()) {
t_base_type* tbase_type = (t_base_type*)ttype;
switch (tbase_type->get_base()) {
case t_base_type::TYPE_STRING:
if (tbase_type->is_binary()) {
-f_gen_ << "\"" << tvalue->get_string() << "\""<<
".to_owned().into_bytes()";
+if (isowned) {
Review comment:
Will there ever be a point where we want the const string/byte-array to be
owned?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Rust const string calls function at compile time
>
>
> Key: THRIFT-4662
> URL: https://issues.apache.org/jira/browse/THRIFT-4662
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Compiler
>Affects Versions: 0.11.0
> Environment: C:\Users\jake>rustup show
> Default host: x86_64-pc-windows-msvc
> stable-x86_64-pc-windows-msvc (default)
> rustc 1.30.0 (da5f414c2 2018-10-24)
>Reporter: J W
>Assignee: Allen George
>Priority: Major
>
> *For this thrift:*
> const string broker_playback_message = "mmi.developer.playback"
> *Generates:*
> // thrift -gen rs -out ../rust/thrift/src const_string.thrift
> pub const BROKER_PLAYBACK_MESSAGE: String =
> "mmi.developer.playback".to_owned();
> *Fails to compile:*
> error[E0015]: calls in constants are limited to tuple structs and tuple
> variants
> note: a limited form of compile-time function evaluation is available on a
> nightly compiler via `const fn`
> *Fix:*
> Probably want to output:
> pub const BROKER_PLAYBACK_MESSAGE: &str = "mmi.developer.playback";
>
> Looking at render_const_value() it looks like byte arrays will have the same
> issue.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4662) Rust const string calls function at compile time
[ https://issues.apache.org/jira/browse/THRIFT-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16678211#comment-16678211 ] ASF GitHub Bot commented on THRIFT-4662: allengeorge commented on issue #1624: THRIFT-4662: Rust const string calls function at compile time URL: https://github.com/apache/thrift/pull/1624#issuecomment-436619709 @jake-ruyi Thank you for the bug report - and the PR! I've asked a question about the implementation. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Rust const string calls function at compile time > > > Key: THRIFT-4662 > URL: https://issues.apache.org/jira/browse/THRIFT-4662 > Project: Thrift > Issue Type: Bug > Components: Rust - Compiler >Affects Versions: 0.11.0 > Environment: C:\Users\jake>rustup show > Default host: x86_64-pc-windows-msvc > stable-x86_64-pc-windows-msvc (default) > rustc 1.30.0 (da5f414c2 2018-10-24) >Reporter: J W >Assignee: Allen George >Priority: Major > > *For this thrift:* > const string broker_playback_message = "mmi.developer.playback" > *Generates:* > // thrift -gen rs -out ../rust/thrift/src const_string.thrift > pub const BROKER_PLAYBACK_MESSAGE: String = > "mmi.developer.playback".to_owned(); > *Fails to compile:* > error[E0015]: calls in constants are limited to tuple structs and tuple > variants > note: a limited form of compile-time function evaluation is available on a > nightly compiler via `const fn` > *Fix:* > Probably want to output: > pub const BROKER_PLAYBACK_MESSAGE: &str = "mmi.developer.playback"; > > Looking at render_const_value() it looks like byte arrays will have the same > issue. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (THRIFT-4662) Rust const string calls function at compile time
[
https://issues.apache.org/jira/browse/THRIFT-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16678281#comment-16678281
]
ASF GitHub Bot commented on THRIFT-4662:
jake-ruyi commented on a change in pull request #1624: THRIFT-4662: Rust const
string calls function at compile time
URL: https://github.com/apache/thrift/pull/1624#discussion_r231521483
##
File path: compiler/cpp/src/thrift/generate/t_rs_generator.cc
##
@@ -673,15 +676,22 @@ void t_rs_generator::render_const_value_holder(const
string& name, t_type* ttype
f_gen_ << endl;
}
-void t_rs_generator::render_const_value(t_type* ttype, t_const_value* tvalue) {
+void t_rs_generator::render_const_value(t_type* ttype, t_const_value* tvalue,
bool isowned) {
if (ttype->is_base_type()) {
t_base_type* tbase_type = (t_base_type*)ttype;
switch (tbase_type->get_base()) {
case t_base_type::TYPE_STRING:
if (tbase_type->is_binary()) {
-f_gen_ << "\"" << tvalue->get_string() << "\""<<
".to_owned().into_bytes()";
+if (isowned) {
Review comment:
Honestly, I'm not really sure about the byte-arrays. We aren't using them
anywhere, so I'm not clear on the use-cases.
I assume it will end up like the regular strings where you might want
`map` or something like that.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Rust const string calls function at compile time
>
>
> Key: THRIFT-4662
> URL: https://issues.apache.org/jira/browse/THRIFT-4662
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Compiler
>Affects Versions: 0.11.0
> Environment: C:\Users\jake>rustup show
> Default host: x86_64-pc-windows-msvc
> stable-x86_64-pc-windows-msvc (default)
> rustc 1.30.0 (da5f414c2 2018-10-24)
>Reporter: J W
>Assignee: Allen George
>Priority: Major
>
> *For this thrift:*
> const string broker_playback_message = "mmi.developer.playback"
> *Generates:*
> // thrift -gen rs -out ../rust/thrift/src const_string.thrift
> pub const BROKER_PLAYBACK_MESSAGE: String =
> "mmi.developer.playback".to_owned();
> *Fails to compile:*
> error[E0015]: calls in constants are limited to tuple structs and tuple
> variants
> note: a limited form of compile-time function evaluation is available on a
> nightly compiler via `const fn`
> *Fix:*
> Probably want to output:
> pub const BROKER_PLAYBACK_MESSAGE: &str = "mmi.developer.playback";
>
> Looking at render_const_value() it looks like byte arrays will have the same
> issue.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Can changes for the 0.12.0 compiler still be submitted?
All changes since the branch was taken should be scrutinized, including build system changes, for inclusion in 0.12.0. I haven't seen any follow-ups since my review comments on the 0.12.0 build. - Jim On Wed, Nov 7, 2018 at 6:52 AM Allen George wrote: > Hi all - > > I’d like to cherry-pick a couple of PRs for the rust generator to the > 0.12.0 branch. I know a message was sent about the branch being cut. Has > packaging started yet? That is, is it too late for these generator changes > to make it in for 0.12.0? > > Thanks, > Allen >
Re: Can changes for the 0.12.0 compiler still be submitted?
Looking at the diff [1] most changes seem safe to include except da1169d - I'm not familiar enough with JS to comment on that. Cheers, Can [1] https://github.com/apache/thrift/compare/0.12.0...master On Wed, 7 Nov 2018, at 16:58, James E. King III wrote: > All changes since the branch was taken should be scrutinized, including > build system changes, for inclusion in 0.12.0. > I haven't seen any follow-ups since my review comments on the 0.12.0 build. > > - Jim > > On Wed, Nov 7, 2018 at 6:52 AM Allen George wrote: > > > Hi all - > > > > I’d like to cherry-pick a couple of PRs for the rust generator to the > > 0.12.0 branch. I know a message was sent about the branch being cut. Has > > packaging started yet? That is, is it too late for these generator changes > > to make it in for 0.12.0? > > > > Thanks, > > Allen > >
[jira] [Updated] (THRIFT-4214) map key treated as hex value in JavaScript
[
https://issues.apache.org/jira/browse/THRIFT-4214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Teodor Atroshenko updated THRIFT-4214:
--
Component/s: (was: JavaScript - Library)
(was: JavaScript - Compiler)
Node.js - Library
Node.js - Compiler
> map key treated as hex value in JavaScript
> -
>
> Key: THRIFT-4214
> URL: https://issues.apache.org/jira/browse/THRIFT-4214
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Compiler, Node.js - Library
>Affects Versions: 0.10.0
>Reporter: Teodor Atroshenko
>Priority: Critical
> Labels: easyfix
>
> The service is defined with the following function:
> {code:javascript}
> map someFunctionName()
> {code}
> The --gen js:node code:
> {code:javascript}
> output.writeFieldBegin('success', Thrift.Type.MAP, 0);
> output.writeMapBegin(Thrift.Type.I64, Thrift.Type.DOUBLE,
> Thrift.objectLength(this.success));
> for (var kiter18 in this.success)
> {
> if (this.success.hasOwnProperty(kiter18))
> {
> var viter19 = this.success[kiter18];
> output.writeI64(kiter18);
> output.writeDouble(viter19);
> }
> }
> output.writeMapEnd();
> output.writeFieldEnd();
> {code}
> String {{kiter18}} is passed to {{output.writeI64}}. Only *TBinaryProtocol*
> is affected by this. The function
> [defenition|https://github.com/apache/thrift/blob/19baeefd8c38d62085891d7956349601f79448b3/lib/nodejs/lib/thrift/binary_protocol.js#L137]:
> {code:javascript}
> TBinaryProtocol.prototype.writeI64 = function(i64) {
> if (i64.buffer) {
> this.trans.write(i64.buffer);
> } else {
> this.trans.write(new Int64(i64).buffer);
> }
> };
> {code}
> *Int64*
> [constructor|https://github.com/broofa/node-int64/blob/master/Int64.js#L49]
> accepts the following arguments:
> * new Int64(buffer\[, offset=0]) - Existing Buffer with byte offset
> * new Int64(Uint8Array\[, offset=0]) - Existing Uint8Array with a byte offset
> * new Int64(string) - Hex string (throws if n is outside int64
> range)
> * new Int64(number) - Number (throws if n is outside int64 range)
> * new Int64(hi, lo) - Raw bits as two 32-bit values
> What happens, is that JavaScript object keys are always Strings, so the
> generated function passes the object key as-is (in String representation) and
> *Int64* library assumes it's a hex string and converts it to a different
> 64-bit integer.
> For example {{"4398046511580"}} becomes {{\[Int64 value:1189123005158784
> octets:00 04 39 80 46 51 15 80]}}
> This also happens when returning {{list}}, however in lists it can be
> bypassed by calling {{Number()}} on all Array elements before passing it to
> Thrift's {{result()}} function.
> To solve this, the compiler can be adding {{Number()}} around everything that
> is a decimal number that is passed to {{writeI64}}; and if {{writeI64}} will
> never be called with an actual hex string, then js library can be updated to
> include the {{Number()}} call around *Int64* constructor argument.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4214) map key treated as hex value in JavaScript
[
https://issues.apache.org/jira/browse/THRIFT-4214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16678663#comment-16678663
]
ASF GitHub Bot commented on THRIFT-4214:
thexeos commented on issue #1519: THRIFT-4214: map key treated as
hex value in JavaScript
URL: https://github.com/apache/thrift/pull/1519#issuecomment-436743619
@MateuszJeziorski I see. So tests for this should really go into
https://github.com/apache/thrift/blob/master/lib/nodejs/test/test-cases.js
@jeking3 I've updated Jira to list Node.js
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> map key treated as hex value in JavaScript
> -
>
> Key: THRIFT-4214
> URL: https://issues.apache.org/jira/browse/THRIFT-4214
> Project: Thrift
> Issue Type: Bug
> Components: Node.js - Compiler, Node.js - Library
>Affects Versions: 0.10.0
>Reporter: Teodor Atroshenko
>Priority: Critical
> Labels: easyfix
>
> The service is defined with the following function:
> {code:javascript}
> map someFunctionName()
> {code}
> The --gen js:node code:
> {code:javascript}
> output.writeFieldBegin('success', Thrift.Type.MAP, 0);
> output.writeMapBegin(Thrift.Type.I64, Thrift.Type.DOUBLE,
> Thrift.objectLength(this.success));
> for (var kiter18 in this.success)
> {
> if (this.success.hasOwnProperty(kiter18))
> {
> var viter19 = this.success[kiter18];
> output.writeI64(kiter18);
> output.writeDouble(viter19);
> }
> }
> output.writeMapEnd();
> output.writeFieldEnd();
> {code}
> String {{kiter18}} is passed to {{output.writeI64}}. Only *TBinaryProtocol*
> is affected by this. The function
> [defenition|https://github.com/apache/thrift/blob/19baeefd8c38d62085891d7956349601f79448b3/lib/nodejs/lib/thrift/binary_protocol.js#L137]:
> {code:javascript}
> TBinaryProtocol.prototype.writeI64 = function(i64) {
> if (i64.buffer) {
> this.trans.write(i64.buffer);
> } else {
> this.trans.write(new Int64(i64).buffer);
> }
> };
> {code}
> *Int64*
> [constructor|https://github.com/broofa/node-int64/blob/master/Int64.js#L49]
> accepts the following arguments:
> * new Int64(buffer\[, offset=0]) - Existing Buffer with byte offset
> * new Int64(Uint8Array\[, offset=0]) - Existing Uint8Array with a byte offset
> * new Int64(string) - Hex string (throws if n is outside int64
> range)
> * new Int64(number) - Number (throws if n is outside int64 range)
> * new Int64(hi, lo) - Raw bits as two 32-bit values
> What happens, is that JavaScript object keys are always Strings, so the
> generated function passes the object key as-is (in String representation) and
> *Int64* library assumes it's a hex string and converts it to a different
> 64-bit integer.
> For example {{"4398046511580"}} becomes {{\[Int64 value:1189123005158784
> octets:00 04 39 80 46 51 15 80]}}
> This also happens when returning {{list}}, however in lists it can be
> bypassed by calling {{Number()}} on all Array elements before passing it to
> Thrift's {{result()}} function.
> To solve this, the compiler can be adding {{Number()}} around everything that
> is a decimal number that is passed to {{writeI64}}; and if {{writeI64}} will
> never be called with an actual hex string, then js library can be updated to
> include the {{Number()}} call around *Int64* constructor argument.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Can changes for the 0.12.0 compiler still be submitted?
A bit of background on that commit since I authored it: The feature is behind a new compiler flag which hasn't been released yet, so it should be safe to include as well as a non-breaking feature addition. If you want to cherry pick it, I think it's fine but it isn't critical to include it. -Brian On 11/7/18, 11:24 AM, "Duru Can Celasun" wrote: Looking at the diff [1] most changes seem safe to include except da1169d - I'm not familiar enough with JS to comment on that. Cheers, Can [1] https://github.com/apache/thrift/compare/0.12.0...master On Wed, 7 Nov 2018, at 16:58, James E. King III wrote: > All changes since the branch was taken should be scrutinized, including > build system changes, for inclusion in 0.12.0. > I haven't seen any follow-ups since my review comments on the 0.12.0 build. > > - Jim > > On Wed, Nov 7, 2018 at 6:52 AM Allen George wrote: > > > Hi all - > > > > I’d like to cherry-pick a couple of PRs for the rust generator to the > > 0.12.0 branch. I know a message was sent about the branch being cut. Has > > packaging started yet? That is, is it too late for these generator changes > > to make it in for 0.12.0? > > > > Thanks, > > Allen > >
[jira] [Updated] (THRIFT-4663) Request payload is two endpoints concatenated together
[
https://issues.apache.org/jira/browse/THRIFT-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Wire updated THRIFT-4663:
---
Description:
Originally encountered as a 500 error received from our server.
Investigating the logs on the server came up with this:
{{02:52:33 _elem152 = iprot.readString().decode('utf-8') if sys.version_info[0]
== 2 else iprot.readString()}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py",
line 184, in readString}}
{{02:52:33 return binary_to_str(self.readBinary())}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py",
line 233, in readBinary}}
{{02:52:33 self._check_string_length(size)}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py",
line 47, in _check_string_length}}
{{02:52:33 self._check_length(self.string_length_limit, length)}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py",
line 58, in _check_length}}
{{02:52:33 'Negative length: %d' % length)}}
{{02:52:33 thrift.transport.TTransport.TTransportException: Negative length:
-2147418111}}
It also turned out that this was hitting a different a different processor than
expected.
Upon inspection of the request in the browser client I noticed that the payload
was two processors concatenated together, in this particular case
'get_usersget_episodes'. The failure, I believe, is because it's executing the
get_users processor and trying to turn get_episodes into the parameters for
that processor.
Finally, we realized that we were trying to make get_users request with the
user_ids array (one of the parameters) containing only a null element. [null].
This request is never sent and seems to hang out waiting for the next request
to be sent.
I would expect thrift to send this poorly formed request, with the [null]
parameter, to the server where it could generate an exception or for it to
generate an exception on the client side that we can track. Having the
half-formed request payload sent along with the next request produced an issue
which was unnecessarily hard to root cause.
was:
Originally encountered as a 500 error received from our server.
Investigating the logs on the server came up with this:
{{02:52:33 _elem152 = iprot.readString().decode('utf-8') if sys.version_info[0]
== 2 else iprot.readString()}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py",
line 184, in readString}}
{{02:52:33 return binary_to_str(self.readBinary())}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py",
line 233, in readBinary}}
{{02:52:33 self._check_string_length(size)}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py",
line 47, in _check_string_length}}
{{02:52:33 self._check_length(self.string_length_limit, length)}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py",
line 58, in _check_length}}
{{02:52:33 'Negative length: %d' % length)}}
{{02:52:33 thrift.transport.TTransport.TTransportException: Negative length:
-2147418111}}
It also turned out that this was hitting a different a different processor than
expected.
Upon inspection of the request in the browser client I noticed that the payload
was two processors concatenated together, in this particular case
'get_usersget_episodes'. The failure, I believe, is because it's executing the
get_users processor and trying to turn get_episodes into the parameters for
that processor.
Finally, we realized that we were trying to make get_users request with the
user_ids array (one of the parameters) containing only a null element. [null].
This request is never sent and seems to hang out waiting for the next request
to be sent.
> Request payload is two endpoints concatenated together
> --
>
> Key: THRIFT-4663
> URL: https://issues.apache.org/jira/browse/THRIFT-4663
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Library
>Affects Versions: 0.11.0
> Environment: Python backend
> React Javascript frontend
>Reporter: David Wire
>Priority: Major
>
> Originally encountered as a 500 error received from our server.
> Investigating the logs on the server came up with this:
> {{02:52:33 _elem152 = iprot.readString().decode('utf-8') if
> sys.version_info[0] == 2 else iprot.readString()}}
> {{02:52:33 File
> "/usr/local/lib/pyt
[jira] [Created] (THRIFT-4663) Request payload is two endpoints concatenated together
David Wire created THRIFT-4663:
--
Summary: Request payload is two endpoints concatenated together
Key: THRIFT-4663
URL: https://issues.apache.org/jira/browse/THRIFT-4663
Project: Thrift
Issue Type: Bug
Components: JavaScript - Library
Affects Versions: 0.11.0
Environment: Python backend
React Javascript frontend
Reporter: David Wire
Originally encountered as a 500 error received from our server.
Investigating the logs on the server came up with this:
{{02:52:33 _elem152 = iprot.readString().decode('utf-8') if sys.version_info[0]
== 2 else iprot.readString()}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py",
line 184, in readString}}
{{02:52:33 return binary_to_str(self.readBinary())}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py",
line 233, in readBinary}}
{{02:52:33 self._check_string_length(size)}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py",
line 47, in _check_string_length}}
{{02:52:33 self._check_length(self.string_length_limit, length)}}
{{02:52:33 File
"/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py",
line 58, in _check_length}}
{{02:52:33 'Negative length: %d' % length)}}
{{02:52:33 thrift.transport.TTransport.TTransportException: Negative length:
-2147418111}}
It also turned out that this was hitting a different a different processor than
expected.
Upon inspection of the request in the browser client I noticed that the payload
was two processors concatenated together, in this particular case
'get_usersget_episodes'. The failure, I believe, is because it's executing the
get_users processor and trying to turn get_episodes into the parameters for
that processor.
Finally, we realized that we were trying to make get_users request with the
user_ids array (one of the parameters) containing only a null element. [null].
This request is never sent and seems to hang out waiting for the next request
to be sent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4663) Request payload is two endpoints concatenated together
[
https://issues.apache.org/jira/browse/THRIFT-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16678917#comment-16678917
]
Brian Forbis commented on THRIFT-4663:
--
Seems to be related to THRIFT-4564 maybe?
> Request payload is two endpoints concatenated together
> --
>
> Key: THRIFT-4663
> URL: https://issues.apache.org/jira/browse/THRIFT-4663
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Library
>Affects Versions: 0.11.0
> Environment: Python backend
> React Javascript frontend
>Reporter: David Wire
>Priority: Major
>
> Originally encountered as a 500 error received from our server.
> Investigating the logs on the server came up with this:
> {{02:52:33 _elem152 = iprot.readString().decode('utf-8') if
> sys.version_info[0] == 2 else iprot.readString()}}
> {{02:52:33 File
> "/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py",
> line 184, in readString}}
> {{02:52:33 return binary_to_str(self.readBinary())}}
> {{02:52:33 File
> "/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py",
> line 233, in readBinary}}
> {{02:52:33 self._check_string_length(size)}}
> {{02:52:33 File
> "/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py",
> line 47, in _check_string_length}}
> {{02:52:33 self._check_length(self.string_length_limit, length)}}
> {{02:52:33 File
> "/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py",
> line 58, in _check_length}}
> {{02:52:33 'Negative length: %d' % length)}}
> {{02:52:33 thrift.transport.TTransport.TTransportException: Negative length:
> -2147418111}}
> It also turned out that this was hitting a different a different processor
> than expected.
> Upon inspection of the request in the browser client I noticed that the
> payload was two processors concatenated together, in this particular case
> 'get_usersget_episodes'. The failure, I believe, is because it's executing
> the get_users processor and trying to turn get_episodes into the parameters
> for that processor.
> Finally, we realized that we were trying to make get_users request with the
> user_ids array (one of the parameters) containing only a null element.
> [null]. This request is never sent and seems to hang out waiting for the next
> request to be sent.
> I would expect thrift to send this poorly formed request, with the [null]
> parameter, to the server where it could generate an exception or for it to
> generate an exception on the client side that we can track. Having the
> half-formed request payload sent along with the next request produced an
> issue which was unnecessarily hard to root cause.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4451) Rust client fails to communicate with multiplexed perl/c_glib servers
[
https://issues.apache.org/jira/browse/THRIFT-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679271#comment-16679271
]
Allen George commented on THRIFT-4451:
--
Somehow the client is shutting down the connection before it receives the
replies. I'm seeing {FIN}s from the client-> server. I'm sure it's a lifetime
issue...
> Rust client fails to communicate with multiplexed perl/c_glib servers
> -
>
> Key: THRIFT-4451
> URL: https://issues.apache.org/jira/browse/THRIFT-4451
> Project: Thrift
> Issue Type: Bug
> Components: Rust - Library
>Reporter: Allen George
>Assignee: Allen George
>Priority: Major
>
> As stated in description. Minimal case is to comment out everything in the
> Rust {{test_client}} leaving only the {{SecondService}} call behind.
> From what I can tell the Rust socket isn't getting *any* bytes at all for the
> response (i.e. it can't even get the first 4 bytes of the message header).
> There is a {{flush()}} call on the remote side - so that's puzzling.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4663) Request payload is two endpoints concatenated together
[
https://issues.apache.org/jira/browse/THRIFT-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679223#comment-16679223
]
David Wire commented on THRIFT-4663:
That does read pretty similarly. Weird that it's marked as fixed there, are the
javascript library and the node.js library that different?
> Request payload is two endpoints concatenated together
> --
>
> Key: THRIFT-4663
> URL: https://issues.apache.org/jira/browse/THRIFT-4663
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Library
>Affects Versions: 0.11.0
> Environment: Python backend
> React Javascript frontend
>Reporter: David Wire
>Priority: Major
>
> Originally encountered as a 500 error received from our server.
> Investigating the logs on the server came up with this:
> {{02:52:33 _elem152 = iprot.readString().decode('utf-8') if
> sys.version_info[0] == 2 else iprot.readString()}}
> {{02:52:33 File
> "/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py",
> line 184, in readString}}
> {{02:52:33 return binary_to_str(self.readBinary())}}
> {{02:52:33 File
> "/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py",
> line 233, in readBinary}}
> {{02:52:33 self._check_string_length(size)}}
> {{02:52:33 File
> "/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TBinaryProtocol.py",
> line 47, in _check_string_length}}
> {{02:52:33 self._check_length(self.string_length_limit, length)}}
> {{02:52:33 File
> "/usr/local/lib/python3.6/dist-packages/thrift-0.11.0-py3.6-linux-x86_64.egg/thrift/protocol/TProtocol.py",
> line 58, in _check_length}}
> {{02:52:33 'Negative length: %d' % length)}}
> {{02:52:33 thrift.transport.TTransport.TTransportException: Negative length:
> -2147418111}}
> It also turned out that this was hitting a different a different processor
> than expected.
> Upon inspection of the request in the browser client I noticed that the
> payload was two processors concatenated together, in this particular case
> 'get_usersget_episodes'. The failure, I believe, is because it's executing
> the get_users processor and trying to turn get_episodes into the parameters
> for that processor.
> Finally, we realized that we were trying to make get_users request with the
> user_ids array (one of the parameters) containing only a null element.
> [null]. This request is never sent and seems to hang out waiting for the next
> request to be sent.
> I would expect thrift to send this poorly formed request, with the [null]
> parameter, to the server where it could generate an exception or for it to
> generate an exception on the client side that we can track. Having the
> half-formed request payload sent along with the next request produced an
> issue which was unnecessarily hard to root cause.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
