Settings - Avatar mismatch in "Share Somewhere" feature.

[lanitochka17]

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

---

Version Number: 1.4.35-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers): abebemiherat@gmail.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:

Action Performed:

1, Go to settings > share code
2, Observe the different avatars associated with shared code

Expected Result:

The avatar in "Share Somewhere" should match the profile picture

Actual Result:

Avatar in "Share Somewhere" differs from the profile picture

Workaround:

Unknown

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6363690_1706797625346.avater2.1.mp4

View all open jobs on GitHub

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[melvin-bot]

Triggered auto assignment to @amyevans (Engineering), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[amyevans]

The regression is coming from #34486. @tienifr are you available to work on a fix ASAP? Otherwise I can open a revert PR, NBD. cc @arosiclair @sobitneupane

[tienifr]

I can work on this now.

[amyevans]

Okay great, thanks!

[sobitneupane]

@tienifr Is this issue also related to the PR?

[tienifr]

Actually I cannot reproduce this issue on the latest main and I also do not find anything related to #34486. I tried with both default and custom avatar. @amyevans @sobitneupane Could you reproduce this on latest main?

[tienifr]

@sobitneupane I have replied in the issue.

[sobitneupane]

Can you retry with a different email? I can reproduce the issue.

[amyevans]

Yeah, I was reproducing on main:

And with the PR reverted locally could no longer repro.

[tienifr]

With the same emails. I can reproduce on staging but not on main. That's weird. Tested on latest main.

[sobitneupane]

@amyevans I can reproduce the issue even after reverting the changes from this PR.

[amyevans]

Hmm okay maybe it was coincidental that I couldn't repro after revert, not sure at this point. I'll keep testing

[situchan]

I reproduced in production as well

[tienifr]

In my case, I don't know why the BE returns different avatar URLs for the same email on staging and main.

[situchan]

@tienifr can you try main against staging backend?

[tienifr]

@situchan Yes. Using staging server on main reproduced the issue for me. So I think this is a BE issue.

[sobitneupane]

I could not reproduce it on production. @situchan Is this issue also reproducible on production?

[situchan]

I found interesting issue while testing #35570

• At first, avatar was A on profile, B on share code
• I uploaded avatar and deleted
• Avatar changed to B (even not restored back to A)

Now I am not able to reproduce both #35570 and #35560. Both avatars are B

[sobitneupane]

Same here. In production, avatar B persists. But in staging and main, avatar A gets restored.

IMO, if we only use production, we always get avatar B. Avatar A is due to the change made from staging/main.

[tienifr]

Avatar B as @situchan mentioned is the correct one. If you tested on staging first, the staging BE will return avatar A (the incorret) and this will be used in main. Later when you removed the avatar on main, the dev BE will return B. IMO, this is a BE issue because only when I switched to staging server, I could reproduce.

[situchan]

Agree this came from staging backend because I couldn't reproduce both issues at all against production backend.
No matter frontend code (main/staging/production)

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[roryabraham]

I don't think this should be treated as a deploy blocker, because it's not really breaking anything and is just a subtle UI bug.

[melvin-bot]

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

[amyevans]

I don't think this should be treated as a deploy blocker, because it's not really breaking anything and is just a subtle UI bug.

Fair, and agreed!

[mallenexpensify]

Assigned to @tienifr cuz they're working on it.

[tienifr]

I and @situchan came to the conclusion here. This is not a regression from my side.

[melvin-bot]

@amyevans, @mallenexpensify, @tienifr Whoops! This issue is 2 days overdue. Let's get this updated quick!

[amyevans]

Finally got around to looking at this one again, and I see that this Web-E PR, which made the default avatar accountID based in the BE, was on staging the day this regression was identified. Mind taking a look @rlinoz?

[rlinoz]

Sure, I will take a look into it

[rlinoz]

Hey, sorry about this, I misinterpreted the FE code and didn't realize I had to also change it.

Just opened a PR to fix it.

[melvin-bot]

@rlinoz @amyevans @mallenexpensify this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot]

@rlinoz, @amyevans, @mallenexpensify Whoops! This issue is 2 days overdue. Let's get this updated quick!

[rlinoz]

This is deployed in staging and will probably get deployed to prod next week.

[rlinoz]

The PR has been deployed to production, so I think we can close this.