Exception in MQTTClient

[ralphwetzel]

No further debugging possible, no further info available.

[phoddie]

Hard to say what might be going on from the limited information. That exception should never happen in normal operation. My best guess is that the socket disconnected and the driver noticed but the disconnect notification hasn't reached the higher software layer. Does it seem possible that either the server connection or Wi-Fi connection was lost in this case?

One solution would be for the MQTT client to catch the exception and close the socket. That will solve the problem for MQTTT but not other users of the TCP socket. A more general solution is to treat the unexpected write failure as notification that the socket connection is lost, fail silently here, and report the error through the usual onError callback. That would behave as-if the disconnect notification had arrived. Silently failing the write doesn't change anything -- a write made immediately before the socket disconnects might not be delivered either.

[phoddie]

FWIW – reporting via onError is a small change:

    if (ERR_OK != tcp_write_safe(tcp->skt, buffer, needed, TCP_WRITE_FLAG_COPY | TCP_WRITE_FLAG_MORE)) {
        xsTrace("tcp write failed");
        tcpTrigger(tcp, kTCPError);
        return;
    }

[ralphwetzel]

Does it seem possible that either the server connection or Wi-Fi connection was lost in this case?

There was no indication of any major (in the sense of cable disconnected or other systems had noticed & reported) loss of connection.

report the error through the usual onError callback

My view: Priority should be, to catch the exception. Reporting back via onError sounds reasonable. Then the library or the node should handle this onError report and recover accordingly.

Hard to say what might be going on from the limited information

I know. Unfortunately xsbug tends (on my systems) to close the debug status in such situations when you try to expand the tree data in the left hand panels...

[phoddie]

Unfortunately xsbug tends to crash in such situations when you try to expand the tree data in the left hand panels

Never seen that. If you have a way to reproduce that, please open an issue.

There was no indication of any major (in the sense of cable disconnected or other systems had noticed & reported) loss of connection.

OK. Networks are unreliable, so seemingly random failures do happen. The non-determinism makes diagnosing these issues challenging.

[phoddie]

Changes committed to SDK TCP implementations for macOS, Linux, and embedded (lwip) targets. Will propagate to public Moddable SDK repository by week's end.

[ralphwetzel]

Unfortunately xsbug tends to crash in such situations when you try to expand the tree data in the left hand panels

Never seen that. If you have a way to reproduce that, please open an issue.

Done.

[phoddie]

Exception resolved in TCP module. Closing.