Unhandled HTTP Error 502 when sending secure message

[martgil]

From a user report:

Hi,

A couple times in the past couple hours I have gotten this error message when trying to send an email through Flowcrypt. This is using the Firefox browser extension.

Is this a problem on the gmail end, do you think? Are there any settings I should check?

Failed to send message due to: Error: error: 502 when POST-ing https://www.googleapis.com/upload/gmail/v1/users/me/messages/send?uploadType=multipart string: not-a-json -> (no standard err msg)

Reference: https://mail.google.com/mail/u/human@flowcrypt.com/#search/lisa/FMfcgzQbgJJmTSMdJmvdtgdhTpCLtCQb

[martgil]

The issue seemed to happen to both secure emails sent by the FlowCrypt browser extension, whether or not it has attachment or not. And this issue prevents them from sending another secure email from the FlowCrypt browser extension in a certain amount of time.

One of them was a reply to an email that had an attachment, I think. I'm not sure. The other one did not have an attachment. When I tried to resend it from the outbox, same message. When I went and opened it from the draft folder (I don't know if the copy saved as a draft would be the same exact thing that was in the outbox so tried a variety of things.) I also tried creating a whole new message and pasting my text into it, thinking that if there was some glitch in the headers of the email that might clear it out. Even in that case, the same thing happened. It did not happen with every email I sent in that time period, but I can't quite reconstruct the order of which ones went through and which didn't. And there were not a lot of emails in any case.

But I am not completely unable to send ANY new messages. For instance I was able to send a message to you.

[martgil]

From https://developers.google.com/workspace/gmail/api/guides/uploads#best-practices. I feel like this issue were somehow tied with email attachment file uploads. But I am uncertain since I haven't seen the response body from an HTTP 502 they're reporting (I can't reproduce the issue) so I can't recommend whether it'll be a "retry-able"/resumable upload or not.

When uploading media, it is helpful to be aware of some best practices related to error handling.

Resume or retry uploads that fail due to connection interruptions or any 5xx errors, including:
500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
Use an exponential backoff strategy if any 5xx server error is returned when resuming or retrying upload requests. These errors can occur if a server is getting overloaded. Exponential backoff can help alleviate these kinds of problems during periods of high volume of requests or heavy network traffic.
Other kinds of requests should not be handled by exponential backoff but you can still retry a number of them. When retrying these requests, limit the number of times you retry them. For example your code could limit to ten retries or less before reporting an error.
Handle 404 Not Found and 410 Gone errors when doing resumable uploads by starting the entire upload over from the beginning.
Exponential backoff
Exponential backoff is a standard error handling strategy for network applications in which the client periodically retries a failed request over an increasing amount of time. If a high volume of requests or heavy network traffic causes the server to return errors, exponential backoff may be a good strategy for handling those errors. Conversely, it is not a relevant strategy for dealing with errors unrelated to network volume or response times, such as invalid authorization credentials or file not found errors.

Used properly, exponential backoff increases the efficiency of bandwidth usage, reduces the number of requests required to get a successful response, and maximizes the throughput of requests in concurrent environments.

The flow for implementing simple exponential backoff is as follows:

Make a request to the API.
Receive an HTTP 503 response, which indicates you should retry the request.
Wait 1 second + random_number_milliseconds and retry the request.
Receive an HTTP 503 response, which indicates you should retry the request.
Wait 2 seconds + random_number_milliseconds, and retry the request.
Receive an HTTP 503 response, which indicates you should retry the request.
Wait 4 seconds + random_number_milliseconds, and retry the request.
Receive an HTTP 503 response, which indicates you should retry the request.
Wait 8 seconds + random_number_milliseconds, and retry the request.
Receive an HTTP 503 response, which indicates you should retry the request.
Wait 16 seconds + random_number_milliseconds, and retry the request.
Stop. Report or log an error.
In the above flow, random_number_milliseconds is a random number of milliseconds less than or equal to 1000. This is necessary, since introducing a small random delay helps distribute the load more evenly and avoid the possibility of stampeding the server. The value of random_number_milliseconds must be redefined after each wait.

Note: The wait is always (2 ^ n) + random_number_milliseconds, where n is a monotonically increasing integer initially defined as 0. The integer n is incremented by 1 for each iteration (each request).

The algorithm is set to terminate when n is 5. This ceiling prevents clients from retrying infinitely, and results in a total delay of around 32 seconds before a request is deemed "an unrecoverable error." A larger maximum number of retries is fine, especially if a long upload is in progress; just be sure to cap the retry delay at something reasonable, say, less than one minute.

[sosnovsky]

Can be something similar to #5903
Did you ask user if rich-text mode is enabled for encrypted messages?

[martgil]

Could be - let me check.

[martgil]

@sosnovsky - The reporting user does not use the FlowCrypt browser extension's rich text editor mode, so I believe the 502 error is something that occasionally happens on Google's side.