[TECHNICAL] Resource leak in CopyAndUploadContentUrisTask #4806
Conversation
d1b1561 to
bcfe14e
Compare
|
Hi, @joragua |
|
Thanks for your contribution @dataCenter430! 💯 I'll check this PR as soon as possible |
|
Hi, @joragua |
joragua
left a comment
There was a problem hiding this comment.
Just two comments and it's ready @dataCenter430! 👍🏻
bcfe14e to
74b74aa
Compare
|
Thanks for your review, 👍 @joragua |
joragua
left a comment
There was a problem hiding this comment.
LGTM! Let's check that nothing is broken with the changes 🚀
|
Just realised one tiny detail: in the changelog file, you defined it as a After re-checking every kind of involved upload (manual, from camera, external, doc provider, external doc), no problem was found. So, it is approved on my side 💯 @dataCenter430 could you perform the change in the calens file and rebase the branch, to be merged? Thanks for your patience!! |
74b74aa to
59924d7
Compare
|
Hi, @jesmrec thanks for your review. |
i checked it, but i realised you merged |
6c2dfa6 to
62c1f88
Compare
Made-with: Cursor
62c1f88 to
9fe453a
Compare
|
It looks like to be done, no conflict, no error |
|
Thanks to you for your engagement @dataCenter430. Merging... it will be included in |
…UrisTask
Related Issues
Fixes #4797
Summary
Fixes a resource leak in
CopyAndUploadContentUrisTaskreported in #4797.Problem
In the loop over URIs (lines 147–182),
inputStreamandoutputStreamwere reassigned every iteration but never closed inside the loop. Only the last iteration’s streams were closed in the outerfinallyblock, so all previous streams were leaked (file descriptors and memory).Solution
InputStreamandFileOutputStream.inputStream/outputStreamvariables and the stream-closing logic from the outerfinallyblock.Each URI’s streams are now closed at the end of that iteration (normal or exceptional), so no streams are leaked.