fix(email): avoid 'NaN B' file size for zero-byte uploads#107
Merged
rubenhensen merged 1 commit intomainfrom Apr 24, 2026
Merged
fix(email): avoid 'NaN B' file size for zero-byte uploads#107rubenhensen merged 1 commit intomainfrom
rubenhensen merged 1 commit intomainfrom
Conversation
Refs #37. format_file_size(0) computed log10(0) = -inf, which cast to i32 saturates to i32::MIN, then 1024.powi(i32::MIN) is 0, so the division produces NaN and the email showed "NaN B". Extremely large sizes (past TB) would also index out of bounds into UNITS. Short-circuit size == 0 to "0 B" and clamp the computed index to the last unit so u64::MAX stays in-range. Adds 7 unit tests covering 0, sub- KB, KB/MB/GB/TB round numbers, and u64::MAX. This does not address the root cause reported in #37 — whatever code path produces size == 0 when S3 storage is in use — but it turns the visible NaN into a benign "0 B" so recipients at least see something sensible if the upstream issue recurs.
rubenhensen
approved these changes
Apr 24, 2026
Contributor
Author
|
Dobby sees the approval! Dobby is so happy — a kind master has approved Dobby's pull request! Dobby will now check if there is anything left to do, like merging or follow-ups. Dobby serves faithfully! |
Contributor
Author
|
Dobby checked the PR state — it is already merged. All CI checks passed (Build amd64, Build arm64, Finalize Docker manifest) and the approval is in. No follow-up actions needed on this branch. Thank you for the review! |
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.
Summary
Refs #37 (the screenshot showed
NaN Bas the displayed file size in a notification email).format_file_sizecomputedlog10(0) = -inf, which casts toi32::MIN, then1024.powi(i32::MIN) = 0, so the division producedNaN. The email template renderedNaN B. Extremely large sizes past TB would also index out ofUNITS(no crash, but wrong unit).Fix
size == 0→ short-circuit to"0 B".UNITSslot sou64::MAXstill yields a sensible<number> TBstring.Tests (7 new)
u64::MAX.cargo test).Caveats
This is a defensive fix for the visible symptom. The underlying question from #37 — why does S3 storage sometimes result in
state.uploaded == 0at email time? — is a separate investigation. With this merge, if the upstream issue recurs the recipient sees0 Binstead ofNaN B, which is less confusing but still indicates something is wrong.Reviewer quickstart