Script using async/await executes from browser but not from App panel

[bnewman]

I have written my first script using async/await, and it consistently works fine. One strange thing is that I can run the script from a browser but I cannot run it from the App window. When I run it from the App window, the script just seems to pend, even at the first line which is just something banal to update a text line in the html page. Perhaps this is a manifestation of the use of aynch/await, and I'm content to run it only from browser, but if I am doing something wrong, I'd like to correct it.

[Mario]

I have never experienced that.
When you test your script in Chrome, you are using basically the same browser engine (Chromium) IMatch is using in app panels.
You can use remote debugging in Chrome to see what your script is doing in the app panel. Just navigate in Chrome to http://localhost:50520 to see all apps running in IMatch and then click on the name of your app to open it in the Chrome debugger. This should show you what's wrong with the app.

[bnewman]

It's rather strange. Using Chrome, I cannot browse to http://localhost:50520 - I get "this site can't be reached". In IMatch, I setup the Remote Debugging Port to 49777 and I can browse to http://localhost:49777. When I launch my app, and refresh the browser, I get it added line on list of Inspectable WebContents. It shows up as "127.0.0.1:50519//user/create-website-support-files/index.html?cb=2849359". At that point, I open the debugger and then click the link corresponding to my app. I get an exception, but it is in inspector.js and doesn't seem to even reach the app. The debugger is paused on an exception of "Type Error". I don't want to bother with more details, because I don't even know what I am seeing. It looks deep down in the system somewhere.

When I take that URL cited above, and copy it into a new tab of Chrome, the script runs straight through without stopping anywhere in the debugger.

[Mario]

You must of course use the debugging port set up on your machine.
"Type" error can mean so many things. Check the console for error messages. Check the "Net" tab to see if and what your app is requesting from IMatch and if something fails (shown in red).
I have unfortunately no time to debug user-written apps, sorry.

[bnewman]

Thanks for your reply. I certainly didn't expect you to debug anything. I thought that maybe there was possibility some kind of exception when running scripts with async/await. You say it should work the same, so I'll investigate further. Thanks for responding.

[thrinn]

If you are willing to post your script here, maybe some other forum member can have a look at it. Sometimes it only needs another pair of eyes...
My apps also use aync/await and work in a browser as well as in IMatch. There is no fundamental reason why it should not work inside IMatch.

[bnewman]

That's an idea. Before I do that, I plan to strip it down to the minimum to see if I can reach a place where it starts to work inside IMatch, and build it back from there. Failing that, I will then have a really stripped down version that still doesn't run from inside IMatch that I can then post.

[bnewman]

Just to close the open question... I did isolate what was causing the script to pend forever when run inside IMatch. I now know what, but not exactly why. I resolved the issue by revising the script to entirely avoid the situation.

If anyone might be interested in explaining what went wrong, I am attaching the stripped down source of the issue. The script is gathering information about a root category and recursively all of its subcategories into a table for subsequent processing. The intention is to gather information about each category and information about all the files associated with each category. I stripped the script down to just the gathering of the information. The problem is with the code at lines 122-124, specifically line 122. The presence of that line suspends activity when run inside IMatch, but works fine when run from a browser (Chrome or Firefox). It may be that the browser is able to recover whatever is wrong, and in a way to allow operation to resume correctly.

I resolved the problem by changing the procedure to avoid having to make an "await" function call inside a loop. Instead, this information gathering function is split into two functions, one gathers all of the category data recursively into an array based on an awaited "v1/categories" request prior to the call, and then a second async function that makes await calls on for the files associated with each previous collected category in the table. It's slightly less "elegant" than where I started, but simpler... "Occam's razor".

Thanks for responding to earlier posts.