If websocket is not working a boring overlay appears every 1 second

[lisotton]

Hi,

I'm trying to replace a MailDev that we have behind a corporate reverse proxy, which does not support websockets well. And then a boring overlay appears every second because the websocket connection get disconnected.

This could be improved if with some options:

1. Not show the overlay while pooling in background, it is fine to show when the user clicks on the "Inbox" button to force a refresh.
2. Have a configuration to configure the pooling frequency, it could be 5 or 10 seconds instead of every one second.
3. The system detect automatically that websocket is not working properly and stop trying to connect to the websocket and fallback to pooling only.

Unfortunately I will need to keep using MailDev, because the reverse proxy is handled at the corporate level, I don't have access to configure it and with this overlay, it is not a good experience.

Thanks :)

[axllent]

Hi @lisotton. Could you please clarify what you mean with a "boring overlay"? Do you mean the overlay with the spinner in the middle?

This should only happen when Mailpit reconnects to a websocket, meaning it was connected, gets disconnected, and then reconnects again. At this point Mailpit does an automatic refresh the mailbox (or search etc) as the messages may have changed since it's last disconnection (eg: if you hibernate a laptop). It appears this is what you are describing, although this is the first time I've heard of a partially-working websocket - they generally either work or they don't.

1. This is necessary to indicate that the mailbox is reloading. This is not a poll, it's a "refresh" of the current API request. This usually takes milliseconds, but depending on the number of messages in the database, and if a complex search is being done, this can take a couple of seconds.
2. Getting the overlay every 5 or 10 seconds seconds doesn't sound like a good solution. Whilst I could introduce an increasing delay for failed connections, it sounds like your problem isn't connecting to the websocket, it is maintaining the connection.
3. Again, it does not sound like websockets aren't working in your situation, it sounds like your browser cannot maintain a websocket connection, ie: something is breaking the connection. But this may be the right approach for a solution (more below).

Are you able to maintain a connection when you connect directly to Mailpit (not via your proxy)? Could you to please confirm for me is whether you are sure is an issue with the proxy, or is maybe the Mailpit server restarting every second?

If it is definitely your proxy, then maybe the best solution would be for Mailpit to stop reconnecting is there are more than "X" repeated successful websocket connections within a period of time, eg: if there > 3 disconnections within 15 seconds, then stop reconnecting altogether. This approach should be sufficient for bad/slow connections, and only apply to situations like yours. Just to repeat, Mailpit does not automatically poll the messages as these can be very expensive lookups (complex searches, lots of mail), so you could need to click on the inbox to manually refresh (this is what users without websocket support need to do).

I'd appreciate in your feedback, thanks.

[lisotton]

Hi @axllent, thanks for your quick reaction.

Yes, I'm referring to the overlay with the spinner in the middle, but it appear so fast and disappear that looks like the whole page is blinking.

It is not that the websocket is partially working, the point is that the reverse proxy is not maintaining the connection, so as soon as the JavaScript tries to establish the connection with the websocket, the connection is closed at the same instant by the backend and then a request to /api/v1/messages?limit=50 is done. And this keeps happening every 1 second and the page blinking.

If I connect directly to Mailpit, it works fine, but when it goes through the reverse proxy, the websocket is not maintained.

I agree with your solution to stop repeating the refresh if had more than 3 disconnections within a specific period.

About the point 1. I agree that it is necessary to show to the user that the mailbox is reloading, but if this is happening in the background, maybe this is not needed to the user. I agree with you that the feedback is needed if the user clicks on the inbox manually to refresh, otherwise it looks like nothing happened with the click.

[axllent]

Thanks for the feedback @lisotton, very useful information. I am actually considering two different approaches:

1. If there are > 3 successful connections & disconnections within 15 seconds, stop using websockets altogether as there is clearly a persistent issue (like what you have). This would disable websockets entirely until the browser is refreshed (what I explained before).
2. If there is a reconnection within 5 seconds of the last successful connection, do not refresh the mailbox. This would just reconnect and you wouldn't notice anything in the UI other than the icon change (next to the Inbox, see below). The downside is that if there was a message that arrived in this time, you would not see the message unless you refreshed the inbox manually. The other downside of this is that your browser will continue to connect & disconnect in the background for eternity (like it currently does).

I think both approaches have merit, so maybe a combination of the two is the right answer. From your perspective the only thing you would notice is the icon changing 3 times next to Inbox between an envelope (meaning the websocket is connected) and a "refresh icon" (meaning you have to refresh manually) - and after 3 or 4 seconds it'll just stay as the refresh icon.
vs

Let me know if you think this is an acceptable "fix" (workaround) for your issue? If so, I will implement this tomorrow (it's midnight here).

[lisotton]

@axllent I like the first approach, so no connect & disconnect in background forever. But I also like your suggestion of the refresh icon to indicate that the user should refresh it manually.

I think this solution will make Mailpit usable in my condition. We will instruct the users that when they are expecting a new message, they should refresh manually.

Take your time to rest, I'm still in the middle of my day :)

[axllent]

A fix for your issue has been released in v1.18.7. Please feel free to re-open this ticket if you continue to experience issues, and please let me know if it does solve your issue. Thanks.