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
As discussed in #293, all endpoints that accept a limit parameter coerce this value to be within the accepted range and do not fail for values outside that range, so no client-side checking of this value is necessary and might even turn out to be problematic if the accepted range ever changes.
As pointed out in #360, having default values for our limit parameters can be equally problematic. Instead, all limit parameters should default to null and only be added to the request if non-null. This ensures that the server's default value will always be used, unless specified by the library user.
The text was updated successfully, but these errors were encountered:
Info: I just tested server behaviour by removing the limit from parameter lists built in several of our methods and then running relevant samples we provide. All of those I tested do work as expected even if no value for limit is provided.
As discussed in #293, all endpoints that accept a
limit
parameter coerce this value to be within the accepted range and do not fail for values outside that range, so no client-side checking of this value is necessary and might even turn out to be problematic if the accepted range ever changes.As pointed out in #360, having default values for our limit parameters can be equally problematic. Instead, all limit parameters should default to
null
and only be added to the request if non-null. This ensures that the server's default value will always be used, unless specified by the library user.The text was updated successfully, but these errors were encountered: