Repository navigation
Conversation
github-actions
Bot
added
vouch:trusted
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — Image imports now read bounded headers before resizing instead of loading full originals that would be discarded. Existing sizing, encoding, byte limits, fallbacks, and cleanup behavior remain unchanged, keeping the change narrowly scoped. You can add or adjust custom eligibility rules. Learn more. |
|
Important Review skippedReview was skipped as selected files did not have any reviewable changes.
 |
| Layer / File(s) | Summary |
|---|---|
File-based fitting and fallback apps/mobile/src/lib/composerImageFit.ts, apps/mobile/src/lib/composerImages.test.ts |
The new fitter reads image dimensions from bounded file chunks and closes the reader. When dimensions cannot be read, it falls back to base64 fitting. Tests cover format handling, failures, and resource release. |
Composer image input integration apps/mobile/src/lib/composerImages.ts, apps/mobile/src/lib/composerImages.test.ts, apps/mobile/src/lib/composerFiles.test.ts |
Document-picked, photo-library, and pasted images use file-based fitting. Document-picked images reload original base64 when fitted output exceeds the limit. Tests cover preview URIs and cleanup of owned files. |
Estimated code review effort: 3 (Moderate) | ~20 minutes
Change: Refactor
Sequence Diagram(s)
sequenceDiagram
participant ComposerImageInput
participant fitComposerImageFile
participant ImageFile
participant ImageManipulator
ComposerImageInput->>fitComposerImageFile: provide image URI and MIME type
fitComposerImageFile->>ImageFile: read bounded header chunks
ImageFile-->>fitComposerImageFile: return image dimensions
fitComposerImageFile->>ImageManipulator: render when fitting is needed
fitComposerImageFile-->>ComposerImageInput: return base64, URI, and fitted status
Possibly related issues
- [Bug]: iOS: Photo-library PNG shown as 7 MB in Photos is rejected with "exceeds the 10 MB attachment limit" #26482: The issue concerns iOS photo-library PNGs rejected by the 10 MiB attachment limit. This PR changes that path to fit images before the full read and retains the attachment-size check.
Possibly related PRs
- pingdotgg/t3code#21352: Both PRs change document-picked image handling; this PR uses file-based fitting in that path.
- pingdotgg/t3code#26522: Both PRs change mobile image fitting after native rendering; this PR changes dimension reading before the initial render.
- pingdotgg/t3code#26453: Both PRs affect the mobile pasted-image flow; this PR uses file-based fitting for pasted images.
Suggested reviewers: maria-rcks, t3dotgg
Merge Risk: 
38c15
-
The reviewed image-import changes have no identified issue requiring a fix before merge.
Pre-merge checks: 
-
Check name Status Explanation Title check The title is concise, specific, and accurately describes the main performance change: avoiding discarded full image reads before fitting. Description check The description includes complete Problem, Change, Scope and approval, and Verification sections. It explains the behavior change, fallback paths, scope, tests, runtime checks, limitations, and agent … Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request. Full details: Description check
-
Explanation
The description includes complete Problem, Change, Scope and approval, and Verification sections. It explains the behavior change, fallback paths, scope, tests, runtime checks, limitations, and agent usage. The detailed verification supports the stated objectives.
-
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Dismissing prior approval to re-evaluate 38c1555
Problem
Photo import, document import and native file paste read and base64-encode an entire original image before deciding to resize it from its URI. When fitting succeeds, that original base64 is discarded.
Change
Read at most the existing 256 KiB dimension-header bound through an async file handle, then use the same URI renderer, 2000px sizing, PNG policy and JPEG quality. Retain full-original fallback for unsupported handles, unknown dimensions and render failures, plus document output-cap fallback and existing temporary-file ownership. Current main’s removal of the old data-URL clipboard API is preserved, along with discarded-render cleanup and native-image release.
Scope and approval
This is a focused removal of discarded image-import work with unchanged output policy. It introduces no storage redesign, setting or protocol change. #9727 continues to own file-backed draft storage; this is separate preprocessing work. Audit tracker: #189.
Verification
vp test run apps/mobile/src/lib/composerImages.test.ts apps/mobile/src/lib/composerFiles.test.ts: 76 passed. Base picker/paste and document regressions fail on unnecessary full reads; candidate success paths make zero full-original reads. Tests cover PNG/JPEG fitting equivalence, partial reads, closure, unsupported handles, small/corrupt/animated images, render failure, caps and temporary-file deletion.vp run check:changed refs/heads/battery/upstream-main: passed against upstream 53896ae.Executed tests mock native APIs; no physical energy result is claimed. Actual iOS 27 Simulator photo-picker comparison on the iPhone 16 Pro device profile: import the same 3072×2048 transparent PNG on base, remove it, then reimport on candidate. Both produce a 2000×1333 PNG of 8,815,427 bytes, identical encoded SHA-256
93aae09dbf8cfecce5b47fb5051afa68be5e136130f6503235aba893d7ce4311and identical decoded RGBA pixels/alpha range. The draft/image also survives route close/reopen and relaunch. Document picker and native file-paste variants have mocked regression coverage, not native runtime coverage; Android runtime was unavailable.Native proof used the matching development client at 3ca62a5 with six reviewed source overlays, including this change. Those captures establish compatibility at the earlier base; current-main native cleanup and document/paste behavior were not recaptured. No UI appearance change is intended.
Implemented and independently reviewed in fresh GPT-6.1 Sol sessions through the Codex harness in T3 Code.
Current-main verification (2026-10-29)
Integrated upstream dac8b11. Fresh independent Codex/GPT-6.1 Sol high review inspected the frozen contribution with no actionable source findings and independently passed 76 focused tests.
CI=true vp run check:changed dac8b11ddc25bd5da62a367fdb6c3de777ae2986passed after the merge commit, covering only this contribution. Earlier native captures above are historical and were not repeated on this integrated head. New-head CI and review remain required.Implementation and independent review: separate GPT-6.1 Sol/high sessions through Codex in T3 Code.