Skip to content

feat: Hard-limit original image byte size to 2 * max_bytes if recoding fails (#8296)#8300

Open
iequidoo wants to merge 1 commit into
mainfrom
iequidoo/hard-limit-orig-img-size
Open

feat: Hard-limit original image byte size to 2 * max_bytes if recoding fails (#8296)#8300
iequidoo wants to merge 1 commit into
mainfrom
iequidoo/hard-limit-orig-img-size

Conversation

@iequidoo
Copy link
Copy Markdown
Collaborator

@iequidoo iequidoo commented Jun 3, 2026

max_bytes isn't a strict limit for non-avatars (note: it's 500 kB by default), still, we don't want to send a gigabyte if recoding fails.

Also add a comment why we downgrade to Viewtype::File if the image couldn't be decoded.

This PR is to have a separate discussion because the current code looks to have this point missed. I remember there were discussions that we don't have any hard limit because the user may send an image and optimistically switch to another chat or even app expecting that the image will be sent somehow, but i think that if the user really cares, they should check the result, otherwise there may even be no network etc. But i'm not a UX expert. Anyway, the reasoning should be documented and some test added, even if we don't want to change the code. CC @r10s

Related to: #8296

…ing fails (#8296)

`max_bytes` isn't a strict limit for non-avatars (note: it's 500 kB by default), still, we don't
want to send a gigabyte if recoding fails.

Also add a comment why we downgrade to `Viewtype::File` if the image couldn't be decoded.
@iequidoo iequidoo force-pushed the iequidoo/hard-limit-orig-img-size branch from c081082 to f2a315e Compare June 3, 2026 21:53
Comment thread src/blob.rs
context,
"Cannot check/recode image, using original data: {err:#}.",
);
// NB: If the image can't be decoded, but the user had chosen `Viewtype::File`
Copy link
Copy Markdown
Collaborator Author

@iequidoo iequidoo Jun 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this should be documented even at the API level because this isn't just an implementation detail, but an observable behavior

@iequidoo iequidoo marked this pull request as ready for review June 3, 2026 21:55
@iequidoo iequidoo requested a review from nicodh June 3, 2026 21:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant