Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error handling in esp_websocket_client_send_with_opcode() (IDFGH-8053) #111

Closed
BartVanHofwegen opened this issue Aug 13, 2022 · 2 comments
Closed

Comments

@BartVanHofwegen
Copy link

Hi, looking at line 1004/1005 of esp_websocket_client.c it strikes me that there might be an error situation not correctly reflected in the the return value of esp_websocket_client_send_with_opcode() (see my comment in the snippet):

        wlen = esp_transport_ws_send_raw(client->transport, current_opcode, (char *)client->tx_buffer, need_write,
                                        (timeout==portMAX_DELAY)? -1 : timeout * portTICK_PERIOD_MS);
        if (wlen < 0 || (wlen == 0 && need_write != 0)) {
            ret = wlen;  /* <--- BvH HERE */
            ESP_LOGE(TAG, "Network error: esp_transport_write() returned %d, errno=%d", ret, errno);
            esp_websocket_free_buf(client, true);
            esp_websocket_client_abort_connection(client);
            goto unlock_and_return;
        }

When 0 is returned from esp_transport_ws_send_raw() while there was data to send (need_write != 0), the return value is set to 0, which is also ESP_OK. If and only if the transport layer can indeed return 0 in this case, I would suggest:

ret = (wlen < 0) ? wlen : ESP_FAIL;

Before filing a pull request, I would like to know if I am right or if there is more to this...

Thanks for the great components BTW !

@github-actions github-actions bot changed the title Error handling in esp_websocket_client_send_with_opcode() Error handling in esp_websocket_client_send_with_opcode() (IDFGH-8053) Aug 13, 2022
@david-cermak
Copy link
Collaborator

Hi @BartVanHofwegen

Thank you for the report. Yes, this is a bug, but since we return number of bytes rather than esp_err_t type (ESP_OK vs ESP_FAIL):

* @return
* - Number of data was sent
* - (-1) if any errors

I'd suggest adding

    ret = widx;

Or better yet, remove those incorrect types and conversions and return ESP_FAIL;'s :

and simply return -1; on invalid params/etc, and return widx; on happy flow.

@BartVanHofwegen
Copy link
Author

Hi @david-cermak, thanks for the reply.

Or better yet, remove those incorrect types and conversions and return ESP_FAIL;'s :

Good point. BTW returning ESP_FAIL is exactly what I proposed for this particular line indeed. widx is already returned on happy flow as it is. I was just not sure if the transport layer could return 0 (in stead of an error) in this case. If not, the whole condition for this case could simply be trimmed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants