You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description
When subscribing to a parameter event in Node.js, if the data type for the parameter is set to Integer but the assigned value exceeds 9999999999999999 (15 digits), its type changes unexpectedly from 'number' to 'string'. This behavior causes the Parameter.fromParameterMessage function to fail because it expects an integer, not a string.
This issue seems to be related to the following previously reported issues:
Start the Python node and the Node.js code in separate terminals
In a third terminal, update the parameter value to 9999999999999999 using the following command:
ros2 param set /minimal_param_node my_parameter 9999999999999999
You should in Node.js terminal that the parameter integer_value type is number, next type:
Now, update the parameter value to 10000000000000000 with the following command:
ros2 param set /minimal_param_node my_parameter 10000000000000000
Now, the parameter integer_value type is string
Actual Behavior
When the parameter value exceeds 9999999999999999, its data type transitions from number to string in Node.js. This type mismatch causes the Parameter.fromParameterMessage function to fail, as it expects the value to remain an integer.
A possible workaround to handle this issue could look like the following code snippet:
try{convertedMsg=Parameter.fromParameterMessage(msg);returnconvertedMsg;}catch(error){// get typeconstparameterType=msg.value.type;// handle array errorsif(parameterType===ParameterType.INTEGER){msg.value.integer_value=Number(msg.value.integer_value);convertedMsg=Parameter.fromParameterMessage(msg);}}
This workaround allows the application to recover from the type mismatch by explicitly casting the integer_value back to a number before processing the parameter message. However, it only addresses the symptom of the issue and does not resolve the root cause.
Expected Behavior
The casting behavior (converting a string back to number when ParameterType.INTEGER is detected) should be directly detected and implemented in the fromParameterMessage function. This would eliminate the need for external type-handling workarounds and ensure consistency regardless of the parameter value.
The text was updated successfully, but these errors were encountered:
PierreSachot
changed the title
Subscription callback integer type is incorrect if integer_value > 9999999999999999
Subscription callback integer_value type is incorrect
Jan 29, 2025
Hi @PierreSachot thanks for your investigation, as you said, it's due to the limitation of JavaScript when representing integer, BigInt may work for this case (suggested by #836), I haven't check with it. BTW, you are welcome to submit a PR to fix it.
Description
When subscribing to a parameter event in Node.js, if the data type for the parameter is set to
Integer
but the assigned value exceeds9999999999999999
(15 digits), its type changes unexpectedly from'number'
to'string'
. This behavior causes theParameter.fromParameterMessage
function to fail because it expects an integer, not a string.This issue seems to be related to the following previously reported issues:
Environment Details:
0.28.1
Steps To Reproduce
9999999999999999
using the following command:ros2 param set /minimal_param_node my_parameter 9999999999999999
You should in Node.js terminal that the parameter integer_value type is
number
, next type:10000000000000000
with the following command:ros2 param set /minimal_param_node my_parameter 10000000000000000
Now, the parameter integer_value type is
string
Actual Behavior
When the parameter value exceeds
9999999999999999
, its data type transitions fromnumber
tostring
in Node.js. This type mismatch causes theParameter.fromParameterMessage
function to fail, as it expects the value to remain an integer.A possible workaround to handle this issue could look like the following code snippet:
This workaround allows the application to recover from the type mismatch by explicitly casting the integer_value back to a number before processing the parameter message. However, it only addresses the symptom of the issue and does not resolve the root cause.
Expected Behavior
The casting behavior (converting a
string
back tonumber
whenParameterType.INTEGER
is detected) should be directly detected and implemented in thefromParameterMessage
function. This would eliminate the need for external type-handling workarounds and ensure consistency regardless of the parameter value.The text was updated successfully, but these errors were encountered: