mirror of
https://github.com/plankanban/planka.git
synced 2026-02-25 03:14:50 +03:00
Gracefully handle errors when failing to upload an attachment #480
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @TassSinclair on GitHub (Apr 14, 2024).
Context
As raised in #302, it's possible for attachment uploads to fail for reasons outside of Planka's control. However, Planka currently logs these errors to the console and continues displaying a spinner, leading the casual observer to assume that the upload is still continuing.
It would be better for Planka to intercept errors that occur during the upload process, and inform the user.
Scenarios
Focusing on 413 errors; I haven't reviewed the code so I'm not sure which errors are already handled, or what the error scenarios look like
413 Request Entity Too LargeGIVEN a Planka installation, served behind an NGINX reverse proxy
AND the reverse proxy is using the default client max body size (1MB)
WHEN the user uploads a 2MB attachment to a card
AND a spinner shows on the card to represent the attachment upload
AND the server responds with a
413 Request Entity Too LargeTHEN an error is shown to the user, alerting them of the failure (how? toast? A dialog?)
AND the spinner is dismissed
GIVEN a Planka installation, served behind an NGINX reverse proxy
AND the reverse proxy is using the default client max body size (1MB)
AND the user uploads a 2MB attachment to a card
AND the server responds with a
413 Request Entity Too LargeTHEN the error shown includes a link to documentation (wiki? faq?) with suggestions of how to debug the issue.
@meltyshev commented on GitHub (Apr 15, 2024):
Hi! Thanks for reporting this. This really needs to be fixed, I think it will be in the v2 release (if no one wants to fix this sooner via PR).