Repository navigation
fix(chat): send photos offline and fail them promptly - #982
Merged
Merged
Conversation
A chip that failed for a network reason blocked Send, so offline the message stayed in the composer. Only a failure another upload can't fix (moderation, a missing upload constraint) blocks it now. Sending a retryable chip restarts its upload and posts the row as Sending; if the retries run out it lands on Not Delivered with retry, as before.
Offline, each finalization poll waits out its 15s deadline and the 30-poll budget treated it as one more poll, so a photo sat at Sending for about 8 minutes. Three polls lost in a row now throw ErrorBlob.network (about 50s), which the chat uploader keeps retryable, and a retry resumes polling the stored blob rather than uploading again. One or two lost polls after a suspend still recover.
The seal lookup fetches the chat when it isn't cached. Offline that throws ErrorGetChat.transportFailure, which sealUnavailable treated as permanent: the chip failed for good and its pending send was dropped. A transport failure under sealUnavailable is now retryable and reports at the inner error's level, which is suppressed for transport failures.
Double tap only reached text bubbles; on a photo the first tap opened the viewer. Photos that can take a reaction now take the double tap, and their open-the-viewer tap waits for it to fail. Photos that can't react (redacted, still sending) open on a single tap with no wait.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Offline, a photo whose upload failed blocked Send and stayed in the composer. Once a photo got past the store step, losing the network during finalization held its row at Sending for about 8 minutes before Not Delivered. This mirrors the Android fixes in code-payments/code-android-app#1681–#1683.
Send a photo that failed offline. Only a chip that failed for good (moderation, no usable upload constraint, encoding) blocks Send now. Sending a retryable chip restarts its upload and posts the row as Sending; if the retries run out it lands on Not Delivered with retry through the existing
retryMediapath.Stop waiting on finalization after three lost polls. Each offline poll waits out the 15s
.unaryDefaultdeadline, and the 30-poll budget counted it as one more poll. Three lost in a row now throwErrorBlob.network, roughly 50s, which the chat uploader keeps retryable. A retry resumes polling the stored blob rather than uploading again, and one or two lost polls after a suspend still recover.Keep a photo retryable when its chat can't be fetched offline. The seal lookup calls
getChatwhen the chat isn't cached. It already has a 15s deadline, but offline itstransportFailurewas wrapped as a permanentsealUnavailable, so the chip failed for good and the pending send was dropped. A transport failure there is now retryable and reports as suppressed.Double-tap a photo to react. Double tap only reached text bubbles; on a photo the first tap opened the viewer. Photos that can take a reaction now do, and the viewer tap waits for the double tap to fail, so a single tap on those photos opens the viewer about 0.3s later. Redacted and still-sending photos open immediately as before.