This is more of a warning than an issue, as we are intending to fix it in the API. It doesn't need a permanent fix in this repository, but it may need a temporary patch.
The climate explorer backend was originally developed as a web API. Accordingly, functions would receive all their arguments as strings, since the URL which called them provided them as strings. The backend sometimes checks whether a specific parameter has been provided using
if parameter:
# do a calculation with the parameter
else:
# do a calculation without the parameter
This construction worked when parameters are strings but fails in the case of a numeric parameter whose value is zero being supplied as an int 0 instead of a string "0" - the parameter-checking if will conclude the int parameter was not supplied at all because 0 is falsy.
If you need to run the rules engine before the PCEX API has been fixed, you can get around this issue by casting this int to a string.
This is more of a warning than an issue, as we are intending to fix it in the API. It doesn't need a permanent fix in this repository, but it may need a temporary patch.
The climate explorer backend was originally developed as a web API. Accordingly, functions would receive all their arguments as strings, since the URL which called them provided them as strings. The backend sometimes checks whether a specific parameter has been provided using
This construction worked when parameters are strings but fails in the case of a numeric parameter whose value is zero being supplied as an int
0
instead of a string"0"
- the parameter-checkingif
will conclude the int parameter was not supplied at all because 0 is falsy.If you need to run the rules engine before the PCEX API has been fixed, you can get around this issue by casting this int to a string.