vtulluru / node-red-contrib-oracledb-mod

MIT License
4 stars 9 forks source link

Unable to catch error when node cannot connect to Oracle server #27

Closed andrewmathies closed 1 year ago

andrewmathies commented 1 year ago

Describe the bug Hello! I noticed that when the Oracle client fails to connect to a server, an error is logged to the console several times. However, this error is coming from the config node, so there is no way to catch this error in a flow. I want my application to be resilient and be able to handle a situation where it cannot connect to the database server, so it would be better to have this error propagated to the database node in the flow.

The error I see logged is: Oracle-server error connection to localhost:1521/a: ORA-12541: TNS:no listener

To Reproduce Steps to reproduce the behavior:

  1. Place the OracleDB node from this library onto a flow
  2. Create and fill out the DB configuration node, but point it to an address that doesn't exist to simulate the client being unable to connect to the Oracle server
  3. Place a catch node that is set to catch errors for all nodes, and connect a debug node to the output
  4. Deploy the flow and run a test with it
  5. Observe that an error message is logged to the node red console, but no error that can be caught is generated. As far as I can tell the flow just stops executing after it reaches the OracleDB node

Expected behavior An error is thrown that can be handled with a catch node

Screenshots image

Desktop (please complete the following information):

andrewmathies commented 1 year ago

~Also, in my opinion there should be a limit on the number of retries after it fails to connect. Maybe it would be best to make an option for this in case others like the infinite retries~

This already exists with the enable automatic connection checkbox in the config node. I'm not sure if this feature is documented somewhere though

andrewmathies commented 1 year ago

So after reading through the code I realized you are emitting a status change. So I can listen for this with a status node and handle the error, kind of. I still think this should be an actual error but it's better than nothing