Fix report title formula name flash by resolving submitter/manager personal details optimistically

[MelvinBot]

Explanation of Change

When a workspace's report title field uses the formula {report:submit:from:firstName} (or any {report:submit:from:*} / {report:submit:to:*} token), the resolved report name briefly flashed to a different value right after a report was created.

Root cause: the title formula is resolved optimistically on the client in computeOptimisticReportNameWithMetadata (src/libs/ReportUtils.ts), but the FormulaContext it built never populated submitterPersonalDetails / managerPersonalDetails. With those undefined, computePersonalDetailsField returns an empty string, and because report:submit:* tokens are special-cased as "submission info" the empty value is not flagged as unresolved — so an empty/partial reportName was committed to Onyx. The UI then rendered a placeholder ("… owes $0.00" / "New Report") until the backend response arrived with the fully-resolved name. That placeholder → real-name transition is the flash.

This change populates submitterPersonalDetails (from report.ownerAccountID) and managerPersonalDetails (from report.managerID) in the optimistic FormulaContext, sourcing them from the module-level allPersonalDetails already maintained in ReportUtils.ts. The report:submit:from:* / report:submit:to:* tokens now resolve to the real names optimistically, matching what the backend returns, so the name no longer changes on the first render — no flash.

Fixed Issues

$ #99192
PROPOSAL: #99192 (comment)

Tests

// TODO: The human co-author must fill out the tests you ran before marking this PR as "ready for review". Please describe what tests you performed that validate your change worked.

• Verify that no errors appear in the JS console

Offline tests

QA Steps

// TODO: These must be filled out, or the issue title must include "[No QA]."

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

[MelvinBot]

I looked into the failing checks. No code fix is needed — every code-related check is passing (Bun tests, Jest test jobs, typecheck, ESLint, Oxfmt, build, spellcheck, Storybook, React Compiler, etc.).

The only failing check is Check independent approval, whose Verify peer review step failed. That's not a code problem — it enforces that the PR has an independent human reviewer approval, and it will stay red until a reviewer other than the author approves the PR. Pushing a commit can't resolve it.

Next step: get an independent reviewer to approve, and this check will pass.

---

view run

[MelvinBot]

✅ Android test — PASS

Ran the reproduction steps from #99192 on standalone Android NewDot against this PR's branch (claude-reportTitleFormulaFlash).

Result: The workspace report title formula {report:submit:from:firstName} resolved directly to the submitter's first name (Formulon) on report creation — no flash to a placeholder like "New Report" or "… owes $0.00".

Steps performed:

1. Created a workspace and set its report title to {report:submit:from:firstName} (confirmed via the #admins system message: changed custom report name formula to "{report:submit:from:firstName}").
2. Changed the display name to Formulon Melvin so the first name was distinct.
3. Opened the workspace chat and created a new report.
4. Observed the new report's title.

Immediately after creation, the report title already read Formulon — searches for New Report and owes returned no matches in any captured state.

Screenshot

Note: The automated driver captures settled UI states (act → settle → snapshot), so it can't rule out a sub-frame visual flash the way a video can. In every settled state captured (immediately post-creation and after opening the report) the title was already the resolved first name, consistent with the fix. The CI-attached recording is the authoritative source if a frame-level flash needs to be ruled out definitively.

---

view run

[huult]

@MelvinBot Could you shorten this comment or remove it? I don't think we need a comment here.

[huult]

@MelvinBot please update this

[MelvinBot]

Shortened it to a single line that keeps the "why" (avoiding the name flash) — pushed in 13fd952:

// Populate submitter/manager details so `{report:submit:from|to:*}` tokens resolve optimistically, avoiding a name flash on creation.

See src/libs/ReportUtils.ts:7203. Happy to drop it entirely if you'd still prefer no comment.

---

view run

[MelvinBot]

Still no code fix needed — every code check is green (Bun tests, Jest test jobs, typecheck, ESLint, Oxfmt, build, spellcheck, Storybook, React Compiler, etc.).

The two red checks are both human-gated, not code problems:

• Check independent approval (Verify peer review) — requires an independent reviewer (someone other than the author) to approve the PR.
• PR Reviewer Checklist / checklist — requires a reviewer to complete the reviewer checklist on the PR.

Both clear once a reviewer approves and fills out their checklist. Pushing a commit can't resolve either.

---

view run

[huult]

@MelvinBot Check all items on the author checklist, I will verify them later.

[MelvinBot]

Same situation as before — no code fix is possible here. All code checks pass. The two red checks are both human-review gates, not code failures:

• Check independent approval (Verify peer review) — needs an independent reviewer (someone other than the author) to approve.
• PR Reviewer Checklist / checklist — fails until a reviewer completes and submits the reviewer checklist.

Next step: a reviewer needs to review the PR, complete the reviewer checklist, and approve. Both checks will go green then — pushing a commit can't resolve them.

---

view run

[MelvinBot]

✅ Web test — PASS

Ran the reproduction steps from #99192 on Web against this PR's branch (claude-reportTitleFormulaFlash).

Result: The workspace report title formula {report:submit:from:firstName} resolved directly to the submitter's first name (Melvinique) on report creation — no flash to a placeholder like "New Report" or "… owes $0.00".

Steps performed:

1. Created a workspace and set its report title (Workspace → Reports → Default report title) to {report:submit:from:firstName} (read back as Default report title, {report:submit:from:firstName} after save).
2. Changed the display name to Melvinique so the first name was distinct.
3. Opened the workspace chat (Melvinique's expenses) and created a new expense report via + → Create report.
4. Observed the new report's title.

Both the chat-preview report card and the opened report header showed Melvinique immediately — no placeholder text was ever observed.

Screenshots

Note: The automated driver captures settled UI states (act → settle → snapshot), so it can't rule out a sub-frame visual flash the way a video can. In every settled state captured (the chat preview card and the opened report header) the title was already the resolved first name, consistent with the fix. The CI-attached recording is the authoritative source if a frame-level flash needs to be ruled out definitively.

---

view run

[MelvinBot]

✅ Done — I've checked off every item in the PR Author Checklist section of the PR body (38 boxes, including all platform sub-items).

I left the two Verify that no errors appear in the JS console boxes in the Tests and QA Steps sections unchecked, since those aren't part of the author checklist — let me know if you'd like those ticked too.

As requested, these are checked for the checklist gate; please verify the individual items yourself before marking the PR ready for review.

---

view run

[huult]

@MelvinBot ready for review

[MelvinBot]

Re-checked the PR — no code fix is needed. Every code-related check is green (Bun tests, all Jest test jobs, typecheck, ESLint, Oxfmt, build, spellcheck, Storybook, React Compiler, etc.).

The only two red checks are human-process gates that no commit can satisfy:

• Check independent approval (Verify peer review) — needs an independent reviewer (someone other than the author) to approve the PR.
• PR Reviewer Checklist / checklist — needs a reviewer to complete the reviewer checklist.

Next step: have a reviewer approve and fill out the reviewer checklist, and both will turn green.

---

view run

[MelvinBot]

I re-checked after the latest commit (13fd9522). No code fix is needed — every code-related check is passing (Bun tests, all Jest test jobs, typecheck, ESLint, Oxfmt, spellcheck, Storybook, React Compiler, unused-styles, knip, perf tests, etc.).

The only two red checks are process/review gates that no code change can satisfy:

• Check independent approval (Verify peer review) — requires an independent human reviewer to approve the PR.
• PR Reviewer Checklist / checklist — populated when a reviewer completes their checklist.

Both will clear once a reviewer other than the author reviews and approves this PR. There's nothing for me to push.

---

view run

[MelvinBot]

✅ Web test — PASS

Ran the reproduction steps from #99192 on dev NewDot web against this PR's branch (claude-reportTitleFormulaFlash, commit 13fd952).

Result: The workspace report title formula {report:submit:from:firstName} resolved directly to the submitter's first name (Zephyrina) on report creation — no flash to a placeholder like "New Report" or "… owes $0.00".

Steps performed:

1. Set a workspace's custom report title to {report:submit:from:firstName} (confirmed in Reports settings).
2. Changed the display name to Zephyrina so the first name was distinct.
3. Opened the workspace chat and created a new expense report.
4. Observed the new report's title.

The report card in the chat rendered directly as Zephyrina, and the report detail header also showed Zephyrina — no placeholder title was observed at any captured state. No console errors during the flow.

Screenshots

Note: The automated driver captures settled UI states (act → settle → snapshot), so it can't rule out a sub-frame visual flash the way a video can. In every settled state captured the title was already the resolved first name, consistent with the fix. The CI-attached recording is the authoritative source if a frame-level flash needs to be ruled out definitively.

---

view run

[MelvinBot]

Same result as before — no code fix is needed. All code checks are green (Bun tests, Jest test jobs, typecheck, ESLint, Oxfmt, build, spellcheck, Storybook, React Compiler).

The two red checks are both process/human checks that a commit can't resolve:

• Check independent approval — requires an independent reviewer (someone other than the author) to approve the PR.
• PR Reviewer Checklist / checklist — requires a reviewer to fill out and complete the reviewer checklist.

Next step: a reviewer needs to complete the checklist and approve the PR. Nothing to push here.

---

view run

[huult]

@MelvinBot I think we should remove it.

[MelvinBot]

Removed the comment entirely — pushed in 9eb550c. The submitterPersonalDetails / managerPersonalDetails lines now stand on their own with no comment above them.

---

view run

[MelvinBot]

Still no code fix needed — all code checks (Bun/Jest tests, typecheck, ESLint, Oxfmt, build, spellcheck, Storybook, React Compiler) are green.

The two red checks are both reviewer-side gates, not code problems, so a push can't resolve either:

• Check independent approval — needs an independent reviewer (someone other than the author) to approve.
• checklist (PR Reviewer Checklist) — fails with "No PR Reviewer Checklist was found"; it goes green once a reviewer fills out the reviewer checklist on the PR.

Next step: have a reviewer approve the PR and complete the reviewer checklist.

---

view run

[huult]

@MelvinBot ready for review

[MelvinBot]

I re-checked the checks after the latest commits. No code fix is needed — every code-related check passes (Bun tests, all Jest test jobs, typecheck, ESLint, Oxfmt, build, spellcheck, Storybook, React Compiler, and the perf tests).

The two remaining red checks are both non-code gates that no commit can satisfy:

• Check independent approval (Verify peer review) — requires an independent human reviewer's approval.
• PR Reviewer Checklist / checklist — requires a reviewer to complete the checklist on the PR.

Next step: have a reviewer (other than the author) approve the PR and complete the reviewer checklist — both checks will then go green.

---

view run

[MelvinBot]

Still no code fix needed — every code check is green (Bun tests, Jest test jobs, typecheck, ESLint, Oxfmt, build, spellcheck, Storybook, React Compiler, etc.).

The two red checks are both human-action gates, not code problems, so pushing a commit can't turn them green:

• Check independent approval — needs an independent reviewer (someone other than the author) to approve the PR.
• PR Reviewer Checklist / checklist — needs the reviewer to complete the PR Reviewer Checklist.

Next step: have a reviewer approve the PR and fill out the reviewer checklist.

---

view run

[huult]

@MelvinBot This PR is ready for review. Please mark it as ready for review (remove the draft status).

[MelvinBot]

✅ Web test — PASS

Ran the reproduction steps from #99192 on dev NewDot web against this PR's branch (claude-reportTitleFormulaFlash).

Result: The workspace report title formula {report:submit:from:firstName} resolved directly to the submitter's first name (Melvina) on report creation — no flash to a placeholder like "New Report" or "… owes $0.00".

Steps performed:

1. Created a workspace and set its default report title to {report:submit:from:firstName}.
2. Changed the display name to Melvina Testerson so the first name was distinct.
3. Opened the workspace chat and created a new expense report.
4. Observed the new report's title.

Read-back confirmed: the report header text was exactly Melvina, and searches for New Report and owes returned no matches in any settled state.

Screenshots

Note: The automated driver captures settled UI states, so it can't rule out a sub-frame visual flash the way a video can. In every settled state captured the title was already the resolved first name, consistent with the fix. The CI-attached recording is the authoritative source if a frame-level flash needs to be ruled out definitively.

---

view run

[melvin-bot]

@huult Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[MelvinBot]

✅ Done — this PR is now marked Ready for review (draft status removed).

---

view run

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9eb550c0bc

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Pass personal details into the formula helper

Pass the personal-details snapshot through computeOptimisticReportNameWithMetadata() instead of reading the module-level Onyx cache here. The helper's output now silently depends on the asynchronous allPersonalDetails connection, so calls made before hydration or during an account-data transition can still commit empty or stale submitter/manager tokens, and callers or tests cannot supply the authoritative snapshot. The repository specifically requires Onyx-backed library logic to remain pure by accepting this data from its callers. CLAUDE.mdL38-L38

Useful? React with 👍 / 👎.

[huult]

I don't think this is necessary to address because the current implementation is correct, and changing it would add unnecessary complexity without providing much value.

[MelvinBot]

I re-checked the failing checks. No code fix is needed — every code-related check passes (Bun tests, Jest test jobs, typecheck, ESLint, Oxfmt, build, spellcheck, Storybook, React Compiler, etc.).

The two red checks are both human-review gates, not code problems, and a commit can't resolve either:

• Check independent approval — requires an independent reviewer (someone other than the author) to approve the PR.
• PR Reviewer Checklist / checklist — requires a reviewer to fill out and complete the reviewer checklist.

Next step: have a reviewer complete the checklist and approve the PR; both checks will then go green.

---

view run

[MelvinBot]

Still no code fix needed — all code-related checks pass (Bun/Jest tests, typecheck, ESLint, Oxfmt, build, spellcheck, Storybook, React Compiler, etc.).

The two red checks are both human-process checks, not code:

• Check independent approval — needs an independent reviewer (someone other than the author) to approve the PR.
• PR Reviewer Checklist / checklist — a reviewer must complete the reviewer checklist on the PR.

Pushing a commit can't satisfy either. Next step: have a reviewer approve and complete the reviewer checklist, and both will go green.

---

view run

[huult]

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified proper code patterns were followed (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Screen.Recording.2026-08-22.at.23.52.52.mov

Android: mWeb Chrome

Screen.Recording.2026-08-22.at.23.51.25.mov

iOS: HybridApp

Screen.Recording.2026-08-22.at.23.55.36.mov

iOS: mWeb Safari

Screen.Recording.2026-08-22.at.23.54.15.mov

MacOS: Chrome / Safari

Screen.Recording.2026-08-22.at.23.48.15.mov

[MelvinBot]

Same as before — no code fix is needed. All 38 code checks pass (Bun tests, Jest test jobs, typecheck, ESLint, Oxfmt, build, spellcheck, Storybook, React Compiler, etc.).

The two remaining failures are both human-review gates that no commit can satisfy:

• Check independent approval — needs an independent reviewer (someone other than the author) to approve the PR.
• PR Reviewer Checklist / checklist — the assigned reviewer needs to complete the reviewer checklist.

Next step: have a reviewer approve the PR and complete their checklist, and both checks will pass.

---

view run

[MelvinBot]

Still no code fix needed — every code-related check passes (Bun tests, Jest test jobs, typecheck, ESLint, Oxfmt, build, spellcheck, Storybook, React Compiler, etc.).

The two red checks are both process/human checks, not code failures:

• Check independent approval — waits for an independent human reviewer to approve the PR.
• PR Reviewer Checklist / checklist — the reviewer's checklist (reviewerChecklist.js) hasn't been completed yet.

Neither can be resolved by a commit. Next step: have a reviewer complete the reviewer checklist and approve the PR, and both will go green.

---

view run

[huult]

LGTM.