App crashes after receiving some packets

[Jaime Martínez Rincón]

I repeatedly get this exception which crashes the app when running on production mode.

In the dev console I get

hoxy error:  ECONNREFUSED { Error: connect ECONNREFUSED 0.0.0.0:80
      at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1161:14)
    errno: 'ECONNREFUSED',
    code: 'ECONNREFUSED',
    syscall: 'connect',
    address: '0.0.0.0',
    port: 80 }

And also

ERROR: Error: connect ECONNREFUSED 0.0.0.0:443
      at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1161:14)

I'm running Linux, I tried installing the AppImage build provided and cloning and running it myself.
It might be useful to know that I run a network wide adblocker, PiHole. Which I thought could interfere with James but disabling it doesn't make James to stop crashing, it didn't seem to help.
I have the certificates correctly generated and I'm proxifying the traffic from an Android device to James.

[Jaime Martínez Rincón]

I worked around this by adding this handler https://github.com/jamezrin/james/commit/231398637e6227ddd44701a4a2ff1b1ef59cb53c

process.on('uncaughtException', (e) => {
  if (e.code === 'ECONNRESET') {
    console.warn('uncaught connection reset'); // eslint-disable-line
  } else if (e.code === 'ECONNREFUSED') {
    console.warn('uncaught refused connection'); // eslint-disable-line
  } else throw e;
});

[Mitchell Hentges]

Dang, looks like an underlying issue is in hoxy.
Global error handlers are a little 👻, but I'll set one up as a temporary measure and do a new release.
Thanks for reporting this and providing a solution!

[Mitchell Hentges]

Hmm, investigating this further, the issue doesn't show up in "development mode" because Electron absorbs the error and logs it.

This explains why it wasn't obvious in local development.
In related news, when I tested the process.on('uncaughtException') locally, it worked in development mode. However, once a release was created, the issue re-appeared.

I'm not sure why Electron is stopping upon receiving a "fatal error" if we're intercepting it. Maybe we need to do something Electron-specific rather than process.on(...)?

Either way, more investigation is needed

[Jaime Martínez Rincón]

Seems to be relationed with greim/hoxy#60 and greim/hoxy#93 (comment), but supposedly it's fixed

[Adam Greene]

Is there a new version of James available with this fix in it??

[Mitchell Hentges]

Not yet, this issue was trickier than it first seemed.
I haven't had the time to debug further into this, but PRs are always welcome :)

[Jaime Martínez Rincón]

I think this is fixed in this PR.
How can this be incorporated into james without having to wait for it to get merged?
The project seems a bit inactive in my opinion.

[Mitchell Hentges]

I've discovered that Sentry, of all things, is related to this problem.
A workaround will be released soon