Crashes with HTML/plugin async operations

[zenibako]

I am using an HTML window to send and receive WebSocket messages:

• My plugin is iterating over a list of messages generated from lines in the script.
• Messages are sent in bundles to the WS client inside the HTML window using window.runJS(...).
• Replies are returned to the plugin with Beat.call((arg) => Beat.custom.handleReply(JSON.stringify(arg)), reply).

The problem appears to be:

• When I iterate over bundles with messages that expect a reply (using a Promise to wait for each bundle to get a reply), the plugin crashes.
• Based on logs, it happens when the window calls the custom function handleReply for only the last iteration.
• If there are multiple bundles, all the bundles process properly (with logs) except for the last one.
• In all cases, the window successfully receives sent messages. The issue is only on the reply back to the Beat window.
• This issue doesn't happen when I send the initial message to establish the connection to the WebSocket server, which is a single message with a reply.

Initially, I thought it had to do with my Promise management, but my Jest tests don't have a problem; it only has an issue when I'm running it in the live Beat app.

Also, I tried using Beat.async() and Beat.sync() as suggested in the wiki, and that doesn't impact the behavior.

Is there a best practice for using Promises in the plugin and waiting for iterations to be fulfilled, especially in regards to interacting back and forth with the window?

FYI, I am launching the function from the menu, which is mounted after the initial connection is made.

Thanks!

[lmparppei]

Could you send me the crash log? I'm very unfamiliar with actual JS, but I think this is some sort of threading issue in Beat code.

[zenibako]

Sure, here's the Apple crash report. Is that what you're needing?

beat-crash.txt

[lmparppei]

By the looks of it, this looks like an infinite loop when logging something. Out of curiosity, try removing all logging just to see if that's the cause.

[zenibako]

OK, tried it again while removing all the logging from the main thread (I either commented them out or put them behind a debug function then used a flag to avoid calling them).

I open the Developer Console as well, and nothing is being logged when I execute the send command.

beat-crash.txt

[lmparppei]

Can you show the actual code of the handler? This is an infinite loop somewhere, and I'm not sure if it's actually Beat code that's causing it.

[zenibako]

Thanks for the final push to publish my code to GitHub :).

Here are the primary sources that are involved here:

• src/data/repositories/cues.ts
• src/data/sources/beat-plugin.ts
• src/data/transfer-objects/beat-window.ts

Hope that helps!

[lmparppei]

Sorry, I don't really know too much JS or TS for that matter. Could you describe the logic how you are calling the custom methods? If I'm reading this right, you are always redefining the handleReply method whenever sending something? I'm not sure if this might cause issues or not. The infinite loop is caused by some callback calling another callback, and that calling the same callback and so on.

Could you produce a minimal example which exhibits this behavior, maybe just a window and async calls, without any of the OSC stuff?

[zenibako]

OK, that is good info: I can look into a pattern that avoids redefining handleReply.

I can try to produce a minimal example, but I also might take another angle with this. I'll let you know soon if I find out more or manage to lay out the logic more clearly.

Thanks again for looking at this! The application-level stuff is a total black box for me so I appreciate the support.