ECONNRESET when using fastGet exits my script instead of throwing an error

I have a script that loops over several thousands of files on the FTP. I’m using fastGet to download each file. The script runs for several hours. Sometimes ECONNRESET is thrown when using fastGet in (as it seems) a random moment (2 out of 3 last runs). And it breaks my script.

The problem is that the following code does not work as I’d expect it to:

try {
    await sftpClient.fastGet(filepath, targetFilepath);
} catch (error) {
    console.log("This never executes, but I expect it to.");
    console.log("I'd be happy to put some code to re-establish the FTP connection here.");
}

This is the output of the script:

/my-script/node_modules/ssh2-sftp-client/src/utils.js:80
    throw formatError(err, name);
    ^

Error: : read ECONNRESET
    at formatError (/my-script/node_modules/ssh2-sftp-client/src/utils.js:54:18)
    at Client.<anonymous> (/my-script/node_modules/ssh2-sftp-client/src/utils.js:80:11)
    at Client.emit (events.js:210:5)
    at Socket.<anonymous> (/my-script/node_modules/ssh2/lib/client.js:307:10)
    at Socket.emit (events.js:215:7)
    at emitErrorNT (internal/streams/destroy.js:92:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:60:3)
    at processTicksAndRejections (internal/process/task_queues.js:80:21) {
  code: 'ECONNRESET'
}

So I understand that this is what happens: uncaughtException event is raised. And as described in node.js docs:

The ‘uncaughtException’ event is emitted when an uncaught JavaScript exception bubbles all the way back to the event loop. By default, Node.js handles such exceptions by printing the stack trace to stderr and exiting with code 1, overriding any previously set process.exitCode

---

I’m not sure whether this is a bug or my expectations about try/catch block around fastGet call are wrong.

---

edit: I’m using latest version (4.3.0)

---

edit 2: As node docs state:

The correct use of ‘uncaughtException’ is to perform synchronous cleanup of allocated resources (e.g. file descriptors, handles, etc) before shutting down the process. It is not safe to resume normal operation after ‘uncaughtException’. To restart a crashed application in a more reliable way, whether uncaughtException is emitted or not, an external monitor should be employed in a separate process to detect application failures and recover or restart as needed.

So unfortunately it’s not easy to recover…

[theophilusx]

As the original issue (script exiting due to uncaught exception) has been resolved and I cannot reproduce the other issues, I am going to close this issue. Will release version 5.0.0 later today.

[theophilusx]

The fact the script didn’t just blow up I will take as a win 😃. No, calling end() when the sftp connection has already been closed does not cause an error.