Check the browser dev dashboard to see what it shows. I use BriskBard because it's written in Delphi and it understands this code better than other browsers.
But I've stepped through code at times and it will simply go off into the weeds for no obvious reason. The Console tab then often shows there was an exception raised.
JS is kind of weird in the sense that it does not throw exceptions the same way that Delphi running in Windows does. It's as if you dial a phone# and get a busy signal (does anybody remember them?) and so you just hang up and move on. In Windows, you'll get an exception. In JS, a NULL is like a busy signal, and it just shrugs and moseys on down the road. A NIL might throw an exception, tho. I've set up a try...except clause around some things like this and sometimes they help, sometimes they don't.
Remember that you have to put [async] in front of methods that you need to call await(...). But one thing that keeps throwing me for a loop is that you also need to put it on methods that call OTHERs with [async] on them. I wish there was a way to turn it on by default for ALL methods that aren't event handlers. I don't know if there's any overhead involved if it's not used, but at present, over half of the non-event methods in my app have that [async] tag on them.
The thing is, I'm not even sure of whether the exception handling stuff requires it ... that is, if you fail to add a try...except clause around an await(...) call and it throws an exception, it may just go off into space if the calling method isn't also a [async] method. They become invisible. You can keep clicking a button to do something that sends a request to a server and nothing seems to happen. You've got to go into the browser's dashboard and step through the code, and see what shows up in the console as well. Or just add a bunch of try...except blocks around the call leading back to the button click. Something will show up eventually. :)
Async + await is an awesome addition to the platform. However, the need to have to think through everything and figure out what all NEEDS [async] on it is annoying. It takes me 30-45 minutes to track down each time one is missing, because it's not always obvious; I'd just rather enable it for everything. That would fix a large number of these mystifying lost requests. (I think many are lost exceptions.)
I've also seen situations where I can see the requests going out, and 200 responses coming back, and my display elements are just ... empty. Nothing's there. The remote server DID, in fact, send a 200 response code ... along with an empty response packet. That raised an exception by the JSON parser and it just threw up its hands and that was that. No runs, no hits, no errors ... and no data.