[HOLD for Testrail] [$2000] When the second picture is uploaded, the first picture that was uploaded earlier starts to load again.

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Open any chat
2. Click on “Add Attachment”
3. Select “Choose from Gallery”
4. Upload same picture multiple times

Expected Result

Each picture should upload smoothly and should not start loading again.

Actual Result

First picture starts to load again once more then one is uploaded.

Workaround:

Can the user still use Expensify without this being fixed? Have you informed them of the workaround?

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.3.0
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

Bug.2.mp4

Expensify/Expensify Issue URL:
Issue reported by: @usmantariq96
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1681508702020879

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~012efb7ba2df1f8cb6
• Upwork Job ID: 1650899886112972800
• Last Price Increase: 2023-05-17

[MelvinBot]

Triggered auto assignment to @twisterdotcom (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[MelvinBot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[twisterdotcom]

I can't reproduce this I'm afraid @usmantariq96. I'm using a Pixel 6. The "loading" circle never appears on the previously uploaded image: https://drive.google.com/file/d/1SsROwvkpTqy8Czds4GVLApEuQau1RWWl/view?usp=sharing

Could you check again for me and reopen the issue if you think it's still an issue?

[allroundexperts]

@twisterdotcom This seems to be easily reproducible for me on Pixel simulator.

screen-recording-2023-04-24-at-125803-am_MP9RsBi8.mp4

[usmantariq96]

@twisterdotcom I have checked again and yes it is reproducible.
Please find attached new video.

[usmantariq96]

Bug.4.mp4

[twisterdotcom]

Ahh I see. Okay yes. I have reproduced it. Super odd we show the loading icon again for attachments.

https://drive.google.com/file/d/1XdGiohePS4o_ym8iTps0JZx3qJ6hO1Ca/view?usp=sharing

[MelvinBot]

Job added to Upwork: https://www.upwork.com/jobs/~012efb7ba2df1f8cb6

[MelvinBot]

Current assignee @twisterdotcom is eligible for the External assigner, not assigning anyone new.

[MelvinBot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @aimane-chnaif (External)

[MelvinBot]

Triggered auto assignment to @joelbettner (External), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[akinwale]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Uploading the same picture twice causes the first uploaded picture to show an activity indicator in the report.

What is the root cause of that problem?

It appears that at some point during the upload process, the system attempts to reuse the same image data from the cache because the uploaded images are effectively the same, which ends up with the image name of the previous uploaded image matching the image name of the newly uploaded image. Although the attachmentInfos for the attachments ultimately end up having different values for the name value, the loading indicator still remains for the first uploaded image.

What changes do you think we should make in order to solve the problem?

To fix this issue, call Str.isImage using props.attachmentInfo.source as the parameter, instead of props.attachmentInfo.name in the ReportActionItemFragment component. The source property represents a URL to the image, and serves as a better option as a unique identifier for the resource rather than just the name of the image.

App/src/pages/home/report/ReportActionItemFragment.js

Line 90 in f3fae40

Str.isImage(props.attachmentInfo.name)

What alternative solutions did you explore? (Optional)

None.

[ShogunFire]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When we upload twice the same image, the second time both images are reloaded

What is the root cause of that problem?

In ImageWithSizeCalculation here:

App/src/components/ImageWithSizeCalculation.js

Lines 91 to 95 in 32fbb2c

	{this.state.isLoading && (
	<FullscreenLoadingIndicator
	style={[styles.opacity1, styles.bgTransparent]}
	/>
	)}

We show the spinner when the image onLoadStart is called. When we load an image with the same url, onLoadStart is executed again.
I believe this is caused by the code in react-native-fastimage here:
https://github.com/Expensify/react-native-fast-image/blob/afedf204bfc253d18f08fdcc5356a2bb82f6a87c/android/src/main/java/com/dylanvann/fastimage/FastImageViewWithUrl.java#L160-L167
We set up a listener: when the resource is ready we trigger the event onLoadStart.
We never unsubscribe from this listener (I don't think it is possible) so when we load another image with the same resource onLoadStart is triggered for the two images.

What changes do you think we should make in order to solve the problem?

Unfortunely I don't think there is a way to remove the listener: https://bumptech.github.io/glide/javadocs/420/com/bumptech/glide/RequestBuilder.html

So I propose that when the image has been loaded successfully here:

App/src/components/ImageWithSizeCalculation.js

Line 62 in 32fbb2c

imageLoadedSuccessfully(event) {

we save the url in the state for example in a variable called urlLoadedSuccessfully and in onLoadStart we verify that the url of the image is different before changing isLoading to true here:

App/src/components/ImageWithSizeCalculation.js

Lines 54 to 56 in 32fbb2c

	imageLoadingStart() {
	this.setState({isLoading: true});
	}

So it will only show the spinner if we are reloading a different image.
It works fine to resolve the issue.

What alternative solutions did you explore? (Optional)

• We can try to add a boolean to FastImageViewWithUrl to know if the resource has already been loaded and check that in the listener before triggering onLoadStart.
• We could also make a change (probably in the backend) so that a picture with the same name has a different url if it's uploaded twice

[twisterdotcom]

@aimane-chnaif any opinions on either of the above proposals? Could we assign @ShogunFire or @akinwale?

[twisterdotcom]

Bump @aimane-chnaif.

[MelvinBot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[twisterdotcom]

@aimane-chnaif - I think given we have @ShogunFire who can somewhat reliably reproduce, even though many of us can't and they believe they have a solution, we should assign them.

@joelbettner would you agree?

[joelbettner]

@twisterdotcom I agree.

[twisterdotcom]

Okay, assigning @ShogunFire.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.23-7 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix the spinner showing when uploading twice the same image on android #19816

If no regressions arise, payment will be issued on 2023-06-12. 🎊

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• External issue reporter
• Contributor that fixed the issue
• Contributor+ that helped on the issue and/or PR

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

• Merged PR within 3 business days of assignment - 50% bonus
• Merged PR more than 9 business days after assignment - 50% penalty

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@aimane-chnaif] The PR that introduced the bug has been identified. Link to the PR:
• [@aimane-chnaif] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@aimane-chnaif] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@aimane-chnaif] Determine if we should create a regression test for this bug.
• [@aimane-chnaif] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@twisterdotcom] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[usmantariq96]

@twisterdotcom applied

[twisterdotcom]

All paid out. @aimane-chnaif - we still need the checklist.

[aimane-chnaif]

@twisterdotcom this is eligible for timeline bonus

[aimane-chnaif]

It's tough to find the offending PR. I think this issue always existed.

• Is it easy to test for this bug? No

• Is the bug related to an important user flow? (For example, adding a bank account) No

• Is it an impactful bug? No

• If the answer is no to all of those questions, you can feel confident we shouldn't create a test for the bug.

[twisterdotcom]

this is eligible for timeline bonus

Why didn't this issue post a comment like this?

@ShogunFire assigned at 11:25 AM GMT +1 on May 30, 2023.
@joelbettner merged it at 10:15 PM GMT +1 on June 1, 2023.

Huh, what on earth is that code even doing then.

[aimane-chnaif]

That comment is when merged in 2 days. But in our case, merged 2 days 11 hrs.
We should definitely update that bot logic to calculate 3 days, not 2 days.
cc: @mountiny

[twisterdotcom]

The code for that is here.

It is looking for 3 days:

    // The urgency bonus applies only when merged within 72 business hours/ 3 days
    if ($daysElapsed < 3) {

But I think there must be something else up with the logic because it should return a false comment as well:

    } else {
        $urgencyComment = <<<COMMENT
        Based on my calculations, the pull request did not get merged within 3 working days of assignment. Please, check out my computations here:

        - when @$authorGithub got assigned: $dateAssignedFormatted
        - when the PR got merged: $nowFormatted
        - days elapsed: $daysElapsed

        On to the next one 🚀
        COMMENT;
    }

Neither of which posted here.

[twisterdotcom]

Bonuses have been sent

[twisterdotcom]

Ahh good old @mountiny is already on it: https://github.com/Expensify/Web-Expensify/pull/37741.