I wonder why no one reported that so far, but this is VERY COMMON error. I would estimate, 1-2% users installing my applicaiton face this error. I don't get complains about that, since typically restarting installation solves the issue, but I get TONS of that errors in my own custom-build crash monitoring. This is the error I get in logs:
Error: spawn C:\Users\User\AppData\Local\tonfotos\Update.exe ENOENT
at ChildProcess._handle.onexit (node:internal/child_process:283:19)
at onErrorNT (node:internal/child_process:478:16)
at process.processTicksAndRejections (node:internal/process/task_queues:83:21) {
errno: -4058,
code: 'ENOENT',
syscall: 'spawn C:\\Users\\User\\AppData\\Local\\tonfotos\\Update.exe',
path: 'C:\\Users\\User\\AppData\\Local\\tonfotos\\Update.exe',
spawnargs: [ '--createShortcut=tonfotos.exe' ]
} uncaughtException
My guess is that the core issue is the problem with Squirrel itself. For some reason it starts application BEFORE all files were finished copying. This does not happen all the time, but as I said 1-2% of the cases. Sometimes it is not Update.exe is missing, but some of the native dependencies I use, and it also leads to crash during install.
I don't even know how to approach to core issue, but I would prefer better error handling of this situation. Actually, all it does diring --squirrel-install call is just creates shortcut. So now, when it fails, application just crashes. Not very good user experience. I would prefer application would start anyway, without throwing any errors, even if it faield creating shortcut for some reason. That would be much more user friendly.
However, that is not possible with current library. Adding try ... catch around require('electron-squirrel-startup') does not help, application crashes anyway. This is due to asynchronous nature of child_process.spawn command. The proper way is to use on('error', ...) on its result, but that requires patching electron-squirrel-startup library. So this is what I ended up doing, but I believe I should report it here, and ask supporters to think about better error handling in this library.
I can provide my pull request, but in reality, this is trivial change, just two lines of code. But that is just to swallow error. Probably you will opt to somehow report it to caller.
I wonder why no one reported that so far, but this is VERY COMMON error. I would estimate, 1-2% users installing my applicaiton face this error. I don't get complains about that, since typically restarting installation solves the issue, but I get TONS of that errors in my own custom-build crash monitoring. This is the error I get in logs:
My guess is that the core issue is the problem with Squirrel itself. For some reason it starts application BEFORE all files were finished copying. This does not happen all the time, but as I said 1-2% of the cases. Sometimes it is not Update.exe is missing, but some of the native dependencies I use, and it also leads to crash during install.
I don't even know how to approach to core issue, but I would prefer better error handling of this situation. Actually, all it does diring
--squirrel-installcall is just creates shortcut. So now, when it fails, application just crashes. Not very good user experience. I would prefer application would start anyway, without throwing any errors, even if it faield creating shortcut for some reason. That would be much more user friendly.However, that is not possible with current library. Adding
try ... catcharoundrequire('electron-squirrel-startup')does not help, application crashes anyway. This is due to asynchronous nature ofchild_process.spawncommand. The proper way is to useon('error', ...)on its result, but that requires patchingelectron-squirrel-startuplibrary. So this is what I ended up doing, but I believe I should report it here, and ask supporters to think about better error handling in this library.I can provide my pull request, but in reality, this is trivial change, just two lines of code. But that is just to swallow error. Probably you will opt to somehow report it to caller.