Sudden tight loop on connection problems
See original GitHub issueDescribe the bug
The system goes to 100% CPU usage, TUYA devices become non-controllable.
To Reproduce Steps to reproduce the behavior:
Wait enough running tuya-mqtt gate.
Expected behavior
-
Either exit the process so that supervisor could restart it, or:
-
Properly guard https://github.com/codetheweb/tuyapi/blob/master/index.js#L138 with chainable
.catch()
so that exception thrown here https://github.com/codetheweb/tuyapi/blob/master/index.js#L275 be caught and passed to the caller.
Debug Output
Jan 03 18:43:27 gate 09270ff75f9d[473]: (node:1) UnhandledPromiseRejectionWarning: Error: No connection has been made to the device.
Jan 03 18:43:27 gate 09270ff75f9d[473]: at TuyaDevice._send (/app/node_modules/tuyapi/index.js:275:13)
Jan 03 18:43:27 gate 09270ff75f9d[473]: at /app/node_modules/tuyapi/index.js:138:14
Jan 03 18:43:27 gate 09270ff75f9d[473]: at new Promise (<anonymous>)
Jan 03 18:43:27 gate 09270ff75f9d[473]: at TuyaDevice.get (/app/node_modules/tuyapi/index.js:135:12)
Jan 03 18:43:27 gate 09270ff75f9d[473]: at GenericDevice.init (/app/devices/generic-device.js:15:46)
Jan 03 18:43:27 gate 09270ff75f9d[473]: at republishDevices (/app/tuya-mqtt.js:68:20)
Jan 03 18:43:27 gate 09270ff75f9d[473]: (node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `-
-unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 3)
Jan 03 18:43:27 gate 09270ff75f9d[473]: (node:1) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Screenshots If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
- OS: Linux gate 5.8.9-1-ARCH #1 SMP PREEMPT Sat Sep 12 20:20:55 UTC 2020 armv7l GNU/Linux
- OS Version 5.8.9-1-ARCH
- Node Version v14.14.0
Additional context Add any other context about the problem here.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (3 by maintainers)
Top Results From Across the Web
gossip: tight loop of loopback connections opened to tighten ...
I don't think that matters, but I noticed it. So Gossip decides that the own node is too far away (already absurd) and...
Read more >Troubleshooting the most typical winding problems of three ...
Among the causes of interphase breakdown are contaminants, tight fit (in the slot), age, mechanical damage, and high-voltage spikes. Coils that ...
Read more >Myofascial Pain Syndrome: Symptoms, Diagnosis & Treatment
Myofascial pain syndrome may be incurable, but symptoms aren't as severe with treatments such as massage, dry needling and muscle relaxants.
Read more >Sudden unilateral hearing loss and vascular loop in ... - NCBI
We present a patient with unilateral sudden sensorineural hearing loss (SSNHL) who was found to have a vascular loop in the ipsilateral internal...
Read more >How to fix your thread looping under the fabric - YouTube
Come learn with me as we figure out how to fix when the thread forms loops under the fabric on your sewing machine....
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Thank you! I believe we’re done with this.
This is the default behavior of the
p-retry
package.Published a fix in v6.1.3.