lmparppei / lmparppei/BeatPlugins
Crashes with HTML/plugin async operations
Nobody has claimed this yet.
- Dominant language
- HTML
- Stars
- 21
- Forks
- 14
- Avg merge
- 5h 20m
- Merged PRs (30d)
- 3
Description
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!
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the menu-launched function in the live Beat app, then compare its final handleReply call with the Jest behavior. Trace the interaction among window.runJS(...), Beat.call(...), and the Promise that waits for each message bundle; done means all bundle replies complete without crashing, including the last iteration.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- html, javascript
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100