[Due for payment 2026-03-30] Workspace settings - Photo is not updated on WS

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: v9.3.40-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-10400/folder/13177080/41237930/1260625268?status_id=1014144&issue_type=jira&folder_ids=13177080%2C31025987&p=2
Email or phone of affected tester (no customers): lattelover1412+1803e@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Web
App Component: Workspace Settings

Action Performed:

Precondition: user has existing WS

Open the link staging.new.expensify.com
User logged in
Navigate to Workspace settings
Click on the Workspace avatar >> Upload an image >> Click "Save"

Expected Result:

Image should be uploaded

Actual Result:

Image is not updated when user attempt to upload as WS avatar

Workaround:

Unknown

Platforms:

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

@Julesssss

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

💬 A slack conversation has been started in #expensify-open-source

👋 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:

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

@VickyStash

Investigation Summary

Classification: Frontend bug
Causing PR: #85248 - "Bump onyx to 3.0.46" by @VickyStash (High confidence)
Related Issues: #76628 (similar previous issue with avatar updates)

Recommendation: REVERT

The PR should be reverted to restore avatar upload functionality. A roll-forward fix would require investigating the interaction between the new synchronous Onyx subscriber behavior and the avatar upload flow.

Labels: Removing DeployBlocker (no backend changes involved)

Detailed Analysis

Evidence

PR #85248 bumped react-native-onyx from 3.0.45 to 3.0.46, which changed subscriber notifications to be more synchronous (removing macro/microtasks). This PR is in the staging deploy (v9.3.40-0) but not in production, matching the reproduction pattern (staging: yes, production: no).

The PR description explicitly states:

"This Onyx update changes subscriber notifications to be more synchronous, which exposed two issues in the App"

While the PR fixed two known issues (side effect in withPolicy HOC and new expense scroll/highlight race condition), the more synchronous behavior likely exposed a new timing issue with workspace avatar uploads.

Verification

File affected: src/pages/workspace/WorkspaceOverviewPage.tsx uses AvatarWithImagePicker with onImageSelected={(file) => updateWorkspaceAvatar(policyID, policy.avatarURL, file as File)}
Upload flow: When user clicks "Save" after cropping, AvatarCropModal calls cropAndSaveImage → onSave(newImage) → updateWorkspaceAvatar → API.write with optimistic data
Optimistic update: Should immediately set policy.avatarURL to file.uri, but something is preventing this from working correctly
PR Bump onyx to 3.0.46 #85248 is in staging deploy: Listed at position 36 in the chronologically ordered PR list in the Deploy Checklist
Similar previous issue: Workpsace - Avatar update not reflected immediately on Overview tab after upload #76628 reported nearly identical symptoms ("Avatar update not reflected immediately on Overview tab after upload") in a previous staging deploy

Root Cause

The more synchronous Onyx subscriber behavior in 3.0.46 appears to create a race condition or timing issue that prevents the optimistic avatarURL update from persisting when uploading workspace avatars. The exact mechanism likely involves:

The optimistic data sets policy.avatarURL to the cropped image file.uri
The synchronous Onyx notifications cause re-renders or policy object updates that either:
- Overwrite the optimistic avatar URL before it can be displayed
- Prevent the avatar component from re-rendering with the new URL
- Interfere with the pending action state that should protect the optimistic update

The fix to withPolicy.tsx (moving updateLastAccessedWorkspace into useEffect) was necessary to prevent "Cannot update a component while rendering" errors, but the broader synchronous behavior change exposed this avatar upload regression.

@MelvinBot

Proposal

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

When a user navigates to Workspace Settings and tries to upload a new workspace avatar image (click avatar → upload image → click "Save"), the image is not updated. This is reproducible on staging (v9.3.40-0) but not on production, indicating a regression in the current release.

What is the root cause of that problem?

The most likely root cause is PR #85231 ("Fix - heic context lost"), which migrated src/libs/cropOrRotateImage/index.ts (the web platform version) from the deprecated manipulateAsync API to the new class-based ImageManipulator.manipulate API from expo-image-manipulator.

The workspace avatar upload flow is:

AvatarWithImagePicker opens AttachmentPicker → user selects image
validateAvatarImage validates the file (extension, size, corruption, resolution)
AvatarCropModal opens → user crops → clicks Save
cropOrRotateImage processes the image (crop/rotate via canvas) → creates a File object
WorkspaceOverviewPage.onImageSelected calls updateWorkspaceAvatar(policyID, avatarURL, file)

Step 4 is where PR #85231 changed the implementation. The old code used the deprecated manipulateAsync(uri, actions, options) function. The new code uses ImageManipulator.manipulate(uri) with chained .crop()/.rotate() calls, then .renderAsync() → .saveAsync().

While both approaches ultimately go through the same expo module (NativeImageManipulatorModule.web.ts → loadImageAsync → canvas operations → blob), the migration introduces a new code path. The old manipulateAsync wrapper internally called context.release() and image.release() after saving, while the new code omits these cleanup calls. More importantly, the new code handles errors differently — if renderAsync() or saveAsync() fails, the promise rejects, and AvatarCropModal catches it at line 329 by only resetting isLoading to false without showing any error message. This means any failure in the image manipulation chain would silently fail.

A secondary contributing factor could be PR #70740 ("Improve and simplify attachment and file validation"), which extensively refactored FileUtils.ts (including validateImageForCorruption used by the avatar validation path) and is already confirmed as the cause of deploy blocker #85671 ("No content to add" error when uploading attachments).

Key evidence:

src/libs/cropOrRotateImage/index.ts:1-32 — The migrated web implementation
src/components/AvatarCropModal/AvatarCropModal.tsx:321-331 — The crop/save flow with silent error handling
src/pages/workspace/WorkspaceOverviewPage.tsx:583-588 — The onImageSelected callback calling updateWorkspaceAvatar
src/libs/actions/Policy/Policy.ts:1688-1731 — The updateWorkspaceAvatar action

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

Option A (Quick fix — revert the web migration): Revert src/libs/cropOrRotateImage/index.ts back to using the deprecated manipulateAsync API. This is the safest fix for unblocking the deploy since the old code was working in production. PR #85231's HEIC fix was primarily for native platforms, and the web version change may not have been necessary.

Option B (Fix forward): Add proper error logging and debugging to cropOrRotateImage/index.ts to identify the exact failure point in the new API chain (manipulate → renderAsync → saveAsync → fetch). Also improve AvatarCropModal's error handling (line 329) to display an error message to the user instead of silently resetting.

I recommend Option A for the deploy blocker fix, with a follow-up investigation for Option B.

What alternative solutions did you explore? (Optional)

Investigated whether useAvatarMenu hook changes caused the issue — confirmed it is only used by profile avatar, NOT workspace avatar
Investigated PR refactor: Improve and simplify attachment and file validation #70740's file validation refactor — while it caused the related deploy blocker [Due for payment 2026-03-30] Attachment - "No content to add" error is shown when uploading attachment #85671, the workspace avatar path uses its own validateAvatarImage from AvatarUtils.ts rather than the refactored validateAttachmentFile.ts, making it less likely to be the direct cause of THIS issue
Checked the expo-image-manipulator web implementation (NativeImageManipulatorModule.web.ts, ImageManipulatorContext.web.ts, ImageManipulatorImageRef.web.ts) — the underlying canvas-based image processing appears correct, but runtime behavior may differ from what the static code suggests

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot to refine this analysis, or explain why you are rejecting Melvin's proposal.

I've just checked this issue over ad-hoc build from Onyx to 3.0.46 bump PR and wasn't able to reproduce it there. So I guess it's not related.

Chrome / v9.3.40-4 PR:85752
Reproduced

Screen.Recording.2026-03-19.at.12.22.23.mp4

@IuliiaHerets

@IuliiaHerets I think you posted a comment in the wrong issue

@VickyStash

@VickyStash I added the wrong video, fixed it already

Passed, Chrome / v9.3.40-6

Screen.Recording.2026-03-19.at.15.26.09.mp4

Thanks! Closing it then

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

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

[CP Staging] Revert "[No QA] Fix lost/duplicated requests in PersistedRequests (Issues 2, 3, 4, 5)" #85804

If no regressions arise, payment will be issued on 2026-03-30. 🎊

@Julesssss

@Julesssss The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

@mallenexpensify

Triggered auto assignment to @mallenexpensify (Awaiting Payment)

Navigation Menu

Repository navigation

[Due for payment 2026-03-30] Workspace settings - Photo is not updated on WS #85673

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Investigation Summary

Recommendation: REVERT

Evidence

Verification

Root Cause

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Due for payment 2026-03-30] Workspace settings - Photo is not updated on WS #85673

Description

Action Performed:

Expected Result:

Actual Result:

Workaround:

Platforms:

Screenshots/Videos

Activity

melvin-bot commented on Mar 18, 2026

melvin-bot commented on Mar 18, 2026

github-actions commented on Mar 18, 2026

OSBotify commented on Mar 18, 2026

Investigation Summary

Recommendation: REVERT

Evidence

Verification

Root Cause

MelvinBot commented on Mar 18, 2026

Proposal

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

What is the root cause of that problem?

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

What alternative solutions did you explore? (Optional)

VickyStash commented on Mar 18, 2026

IuliiaHerets commented on Mar 19, 2026

VickyStash commented on Mar 19, 2026

IuliiaHerets commented on Mar 19, 2026

3 remaining items

m-natarajan commented on Mar 19, 2026

cristipaval commented on Mar 19, 2026

melvin-bot commented on Mar 23, 2026

melvin-bot commented on Mar 23, 2026

melvin-bot commented on Mar 23, 2026

melvin-bot commented on Mar 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions