Under Review
over 1 year ago

Communications.makeWebRequest triggers "Not Enough Arguments Error" when simulating connection failure when using :context option

I tried simulating how Communications.makeWebRequest would perform when the device had no connection. The behavior seems inconsistent with documentation and also non-functional, since it calls the callback with a varying number of arguments.

Reproduction:

  1. Design a Communications.makeWebRequest flow that uses the optional :context option.
  2. Define a callback to accept it, like this:  public function onReply(responseCode as Lang.Number, data as Lang.Dictionary or Lang.String or Null, inContext as Lang.Object) 
  3. Toggle off connections: Settings>Connection Type>BLE>Not Connected and Settings>Connection Type>Wifi>Not Connected
  4. Cause a network call to happen

Outcome:

  • A runtime error occurs, indicating the line number of the callback function definition.  Error is: "Not Enough Arguments Error"

Expected outcome:

  • The number of arguments sent to the callback function should be the same, regardless of the connection state.  It's not possible to know before making the call how many arguments will come back, and monkey c doesn't have the option to mark arguments as optional.

CIQ 4.1.6

Epix (gen2)

  • I'm sure bug WAS on many devices but I don't know how it looks now but I'm not going to test. Bug was from time to time. And I use webREQ in background.

    You should try only for one type of context. Use dictionary as parameter e.g.

    {

    Key => value

    }

    value can by any type.

    I'm not sure it helps 

  • That’s what I do now (context is an object), and it’s causing the error. 

    So this isn’t just a simulator bug? Are you saying that context just isn’t usable on the actual device, since it could cause a runtime error if there’s a connection problem?

    It is working for me fine while I have a connection. I was just trying to see what happened without a connection on the simulator before trying on device. 

  • it was shock for me when I have discovered that not all bugs are fixed.

    btw, I haven't tested, but maybe it will run when context is an object not primitive, so you can put as context dictionary with value of number maybe they have in code if(context) and context can be simple zero or null do

  • > The behavior seems inconsistent with documentation and also non-functional, since it calls the callback with a varying number of arguments.

    To me this is a very interesting class of bug, because you would expect:

    - Garmin to (collectively) understand the constraints of a language Garmin itself designed

    - at the very least, to update the documentation to tell devs not to use the broken form of the callback function

    To me it's a deeper, more systemic problem than "whoops we just don't have enough time to fix all of these bugs :(".

    > Every new developer tries to use context (because it's useful) and faces the bug.

    There's a lot of problems that new devs run into over and over again over the years, same as every new forum poster runs into the same forum bugs, but if you complain too much, certain posters will attack you.

  • But thanks for letting me know I'm not crazy