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

file transfers are no longer queued if they fail #23546

Open
ara4n opened this issue Oct 19, 2022 · 4 comments
Open

file transfers are no longer queued if they fail #23546

ara4n opened this issue Oct 19, 2022 · 4 comments
Labels
A-File-Upload Attachments and file uploads O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience S-Minor Impairs non-critical functionality or suitable workarounds exist T-Defect

Comments

@ara4n
Copy link
Member

ara4n commented Oct 19, 2022

we should have the normal abort/retry button if a file transfer fails. pretty sure we used to have this.

Steps to reproduce

  • Be on bad connectivity (e.g. network conditioner)
  • Try to upload a file
  • Kill the connectivity entirely
  • Note that the file transfer fails with "failed to upload"
  • Look for a "retry unsent messages" button, which used to exist, but no longer exists (but only for file transfers).

Outcome

What did you expect?

File transfers should get queued and retried under bad connectivity, just as normal messages do.

What happened instead?

The file is silently discarded and the user has to manually set up the upload again when they think they might have better connectivity.

Operating system

macOS

Browser information

Chrome 106

URL for webapp

https://develop.element.io

Homeserver

matrix.org

Will you send logs?

No

@amywalkerdev amywalkerdev added T-Defect A-File-Upload Attachments and file uploads labels Oct 19, 2022
@amywalkerdev
Copy link

Thank you for your report. We need some more information from you before our developers can look at it. Please edit your issue to include replies to all sections.

Please comment to let us know when you've had a chance to add more details to the issue.

@amywalkerdev amywalkerdev added S-Minor Impairs non-critical functionality or suitable workarounds exist O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience X-Needs-Info This issue is blocked awaiting information from the reporter labels Oct 19, 2022
@ara4n ara4n removed the X-Needs-Info This issue is blocked awaiting information from the reporter label Oct 26, 2022
@ara4n
Copy link
Member Author

ara4n commented Oct 26, 2022

I've filled in the form (although I thought the problem was already captured in the minimal form; i'm afraid that if i spot a regression while in a rush i'm liable to try to get it on the radar, even if with a partial description, as it's better that than it get lost entirely).

@ara4n
Copy link
Member Author

ara4n commented Oct 31, 2022

This is particularly hellacious in combination with #22998. You try to upload an image, and it blocks before it even gives you a 'send' button. And then it fails, you don't even get a 'retry' button and have to start over, which blocks again... 🤦🏻

@gaelledel
Copy link

This currently works for messages that failed to send. We should therefore display the same banner for anything else including photos, videos, attachments etc...
As a second phase, we will probably modify this and adopt the same behaviour/style as EX. This will come with the timeline rework using Compound.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-File-Upload Attachments and file uploads O-Frequent Affects or can be seen by most users regularly or impacts most users' first experience S-Minor Impairs non-critical functionality or suitable workarounds exist T-Defect
Projects
None yet
Development

No branches or pull requests

4 participants