Please give this a deep thought before going forward. Specifically, I suggest that you do not try to implement any re-connections of your own.
Here is the information you may need:
OPC-UA implements various kind of checks to assure that the client-server connection is truly working. These checks include a bi-directional keep-alive mechanism, and it is this mechanism that is responsible for the error you are seeing.
The checks are time-based, meaning that there is a certain time period during which (I am simplifying here) the server has to respond to the client and the client to the server. While the idea of these checks sounds great and actually does work well in production, it causes a BIG PROBLEM once you start debugging. Debugging often involves pausing the program, and the keep-alive checks then start failing. That's what they are supposed to do, right...?
The sad fact is there is no 100%-guaranteed way around it.
We have a special logic in our component, which works as follows: When we detect that the program is being run under the debugger, and a new OPC-UA session is being created, we modify the usual keep-alive timings on the client side to a very large value (days). This sometimes helps - but not always. There are various reasons why this workaround may fail, for example:
a) The program may be started and the session created without the debugger, and later the debugger is attached and the program paused.
b) (This is probably what happens in your case): The keep-alive checks are bi-directional, and the actual timings used are subject to upfront "negotiation" between the client and the server. Therefore, even if we detect the debugger, and propose a keep-alive several days long, the server may - and often does - revise this value to something that it considers reasonable, bringing us back to where we were.
The bottom line is that the only way out of this may be to devise and use debugging techniques that do NOT involve pausing the program.
And, in case of session-level errors, QuickOPC already has a mechanism to reconnect. All it needs it that its process must be actually given a time to run. If you start trying to do reconnections on your own, you will not help anything, as the debugger has the absolute power over the program, and when it pauses the program, it basically creates a condition that goes against what OPC UA specification imposes on the client behavior. So it is the fact of using the debugger (or, to be more precise, pausing the program) that is ultimately "guilty" here, and not anything else.