Default workflow is not shown after deleting agent approver and duplicating workspace offline

[applause-bot]

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: 9.4.5-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: #92286
Email or phone of affected tester (no customers): applausetester+sdjonisdji12d@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Log in with Expensifail account.
• Create a Control workspace.

1. Go to staging.new.expensify.com
2. Go to Account > Agents.
3. Create an agent.
4. Go to workspace settings > Workflows.
5. Click Add agent on the default workflow > Save.
6. Go to Account > Agents.
7. Go offline.
8. Delete the agent.
9. Go to Workspaces tab.
10. Click 3-dot menu next to the workspace.
11. Click Duplicate workspace.
12. Click Next > Continue.
13. Open the duplicated workspace.
14. Go to Workflows.

Expected Result:

Default workflow will be shown after deleting agent approver and duplicating workspace offline.

Actual Result:

Default workflow is not shown after deleting agent approver and duplicating workspace offline.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7177988_1781190443029.19.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7177988

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/06b6ae7cd1367a0e46e3ab614eb356e3987c3b13ee787023ae95ee85f78f7595

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #92286

[melvin-bot]

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

[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.

[MelvinBot]

Proposal

Regression from PR #92286 (this issue's deploy blocker). Confidence: High — fully traced through the offline flow with code evidence.

What is the root cause of that problem?

Deleting the agent leaves two stale references to it that the workspace‑duplication flow then copies into a policy where the agent no longer exists, so the default workflow can't be reconstructed.

Step by step:

1. Adding the agent as the default‑workflow approver sets policy.approver = agent and points the owner's submitsTo at the agent (Workflow.ts:106, Workflow.ts:170).
2. Deleting the agent (the behavior PR #92286 added) only marks the agent's own employeeList row pendingAction: DELETE (Agent.ts:351‑378). It does not clean up policy.approver or the owner's submitsTo, which both still point at the agent. (Fine so far — the agent's row still exists, so the chain resolves and the original workspace still renders the workflow.)
3. Duplicating the workspace offline strips the agent's row via the pre‑existing filterPendingDeleteData (Policy.ts:3290‑3304), but copies policy.approver and the owner's submitsTo verbatim (Policy.ts:3313) — both now dangling at a removed employee.
4. Building the workflow cards, the owner's submitsTo points at the missing agent, so the guard at WorkflowUtils.ts:188 continues and zero workflows are produced. The default‑workflow fallback is gated on at least one workflow already existing (WorkflowUtils.ts:268‑275), so it never fires → the default workflow card disappears.

Before PR #92286, agent deletion didn't mark the employeeList row, so the agent survived duplication and the chain resolved — which is why this is reproducible only on staging.

Why "not reproducible in production" and other supporting detail

• This is purely an optimistic/offline display bug. Online, DELETE_AGENT runs before DUPLICATE_WORKSPACE; the backend removes the agent and cleans up its references on the source policy before the copy is made, so the duplicate is consistent. The breakage only exists in the offline-queued optimistic state.
• getDefaultApprover returns policy.approver || policy.owner (PolicyUtils.ts:1414) — since policy.approver is still set to the (now-missing) agent, it never falls back to the owner.
• buildOptimisticDuplicatePolicy performs no dangling-reference cleanup — it filters rows but never resets approver/submitsTo/forwardsTo that point at filtered-out employees.

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

Primary (root-cause): In buildOptimisticDuplicatePolicy, after filtering pending‑delete employees, repair references to the removed rows in the duplicated policy:

• if policy.approver points at a filtered‑out employee, reset it to the owner, and
• reset any surviving employee's submitsTo/forwardsTo that points at a filtered‑out employee.

This keeps the duplicated policy internally consistent (and matches what the backend would produce).

Complementary hardening: Make convertPolicyEmployeesToApprovalWorkflows always emit a default workflow even when zero workflows are derived (resolving the default approver to the owner when policy.approver references a non‑existent employee). The default workflow should always be visible regardless of employeeList inconsistencies.

What alternative solutions did you explore? (Optional)

Revert PR #92286 — fastest way to unblock the deploy, since it removes the optimistic employeeList DELETE marking that triggers the filter. Trade‑off: loses the agent strikethrough/RBR display that PR added.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/93302) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.