Skip report name recompute for badge-only policy changes in reportAttributes by TMisiukiewicz · Pull Request #97093 · Expensify/App

TMisiukiewicz · 2026-07-27T12:07:54Z

Explanation of Change

Opening the Spend tab for the first time fires OpenSearchPage, whose server response merges the full policy_ collection (5.6k policies on large accounts). getCollectionDelta is a reference-equality scan, so the merge surfaces ~all policies as "changed" and reportAttributes recomputed the name (computeReportName) for ~all 8245 reports — a ~30s main-thread hang.

Root cause: computeReportName derives a report's name from policy.name / achAccount only (via getPolicyName), never from the badge-relevant fields hasPolicyRelevantFieldChanged tracks (type/approvalMode/reimbursementChoice/autoReimbursementLimit/role/autoReimbursement.limit). Those fields drive LHN badges, not names. Recomputing names for badge-only policy changes was wasted work.

Fix:

Badge/attribute recompute scope is unchanged — reports referencing a changed policy still recompute their badges.
Names are only recomputed for reports touched by a name-affecting source (report/action/nvp/personal-details/transaction/policy-tags updates) or whose policy name (or achAccount) actually changed. A report pulled into the pass solely by a policy badge-field change reuses its cached name and skips computeReportName. This is consistent with existing behavior where a policy-name-only change was already not recomputed.
Also seeds the previousPolicies value-baseline on the startup flush so the first policy trigger has a real baseline to diff against.

Tests: added/updated unit tests in tests/unit/reportAttributesTest.ts (25 total pass), covering: badge-only change keeps cached name; policy name change forces recompute; invoice receiver-policy role change still recomputes the invoice name; and a coalesced badge-change + transaction-update flush still recomputes the name.

Performance improvement:
4x CPU throttling, opening Spend tab goes from ~30s to ~5s

Before vs After

before.mov

after.mov

Fixed Issues

$ #97095
PROPOSAL:

Tests

Setup: an account member of many policies/reports (ideally as many as possible).
Open the Spend tab for the first time after a cold start; verify it's interactive quickly (no long freeze).
Verify report names are correct (not stale/blank) after the policy load for: workspace chats, expense reports, invoice rooms/reports (as sender AND receiver-admin), DMs/groups, and threads.
Rename a workspace and verify the workspace chat + its reports' names update in the LHN.

Verify that no errors appear in the JS console

Offline tests

N/A

QA Steps

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

Same as tests

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

after.mov

melvin-bot · 2026-07-27T12:41:03Z

@situchan 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]

situchan · 2026-07-27T12:41:51Z

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 any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
- 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 and each prop has a /** comment above it */
- The file is named correctly
- 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
- For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
- Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
- All JSX used for rendering exists in the render method
- 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 any new file was added I verified that:
- The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
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

Android: mWeb Chrome

iOS: HybridApp

ios.mov

iOS: mWeb Safari

MacOS: Chrome / Safari

web.mov

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d816bbbee3

ℹ️ 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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f51a475399

ℹ️ 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".

MelvinBot · 2026-07-27T14:31:15Z

Review

The optimization is well-scoped and the approach is sound: only the reportName field is made conditional, while badges/brickRoadStatus/attributes still recompute for every policy-touched report, and every non-policy name source (report/action/nvp/personal-details/transaction/policy-tags) correctly removes its keys from nameSkipKeys. Comments and tests are thorough. I found one correctness edge case worth addressing before merge, plus a couple of minor notes.

🟠 `approvalMode` can feed a report name — a badge-only change may leave a name stale

The skip treats all six hasPolicyRelevantFieldChanged fields as name-irrelevant, but approvalMode is not purely a badge field — it leaks into a report name:

ReportNameUtils.ts:480-489 — a thread off a SUBMITTED/SUBMITTED_AND_CLOSED action returns iou.markedAsDone vs iou.submitted based on shouldShowMarkAsDone({policy: reportPolicy, ...}) (the report's own policy).
ReportUtils.ts:13744-13748 → isSubmitAndClose reads policy.approvalMode === OPTIONAL.
isTrackIntentUser is supplied to computeReportName at reportAttributes.ts:602, so the path is reachable in production.

So a policy-only approvalMode change (with no accompanying report/action update to pull the report out of nameSkipKeys) would skip computeReportName and leave such a thread's name stale. The trigger is narrow — track-intent user, thread off a submitted action, self-submit-and-close — but it's a genuine stale-name case, and approvalMode is the badge field most likely to actually change on its own.

Suggested fix: fold approvalMode into the nameChanged computation so those policies land in nameChangedPolicyIDs and don't get the badge-only skip:

const nameChanged =
    prevPolicy?.name !== nextPolicy?.name ||
    prevPolicy?.achAccount?.accountNumber !== nextPolicy?.achAccount?.accountNumber ||
    prevPolicy?.approvalMode !== nextPolicy?.approvalMode;

This costs a name recompute only when approvalMode actually flips (a rare workspace-config event), and doesn't touch the OpenSearchPage hot path (no-op re-merge), which is where the win comes from. It'd also be worth a unit test for the track-intent submit-and-close thread case. The other four fields (type, reimbursementChoice, autoReimbursementLimit, own-policy role, autoReimbursement.limit) were verified clean — no name path reads them, and the receiver-policy role case is already handled correctly via receiverPolicyChanged.

Minor notes

Pre-existing, not introduced here: MOVED/CHANGE_POLICY action messages read other policies' names (ReportUtils.ts getMovedActionMessage etc.). A report owned by policy A that displays policy B's name in a moved-action message already wasn't recomputed on B's rename, since the policy-change scan only matches by the report's own/receiver policyID. This PR doesn't make it worse — just flagging it since it lives near this logic. Those messages recompute via the report-action path anyway.
The nameChanged comparison on achAccount.accountNumber is a correct superset of what the name reads (accountNumber.slice(-4) in ReportNameUtils.ts:733) — any change to the last 4 implies a change to the full value. 👍
The cachedName !== undefined guard correctly forces a compute for reports not yet in currentValue, so new reports can't accidentally reuse a missing name. 👍
Verified the trigger assumptions the seeding relies on: the startup disk-hydration flush has sourceValues === undefined (baseline-only), and sourceValues[POLICY] is a reference-equality delta of changed members only — so seeding previousPolicies on the no-POLICY-trigger flush and iterating Object.keys(sourceValues[POLICY]) are both correct.

Nice perf win otherwise (~30s → ~5s). Once the approvalMode case is handled (or explicitly ruled out as acceptable), this looks good to me.

situchan · 2026-07-27T14:33:12Z

Regression Analysis:

1 — role change leaves modified-expense thread names stale (confirmed, narrow)

computeReportName → computeChatThreadReportName (MODIFIED_EXPENSE parent, ReportNameUtils.ts:928-943) → getForReportAction({policy, …}) → isPolicyAdmin(policy, currentUserLogin) (ModifiedExpenseMessage.ts:395), which reads policy.role via getPolicyRole. For an MCC-sourced category change the label gains/loses a workspace-rules hyperlink depending on admin status. role is also a tracked badge field, so a role-only change is classified badge-only and the chat-thread name is reused stale. (Also reachable via getRulesModifiedMessage/hasPolicyRuleAccess in the same helper.)

2 — fieldList change leaves empty-name expense report stale (confirmed, non-badge edge)

getMoneyRequestReportName (ReportNameUtils.ts:412-416) returns DEFAULT_EXPENSE_REPORT_NAME ("New Report") when report.reportName === '' && isPolicyFieldListEmpty(policy) — reading policy.fieldList. fieldList is in neither hasPolicyRelevantFieldChanged nor the new nameChanged check. For a fieldList-only change this was already skipped pre-PR (not new), but when a fieldList change coalesces with a badge-field change on the same policy, pre-PR recomputed the name and post-PR reuses the stale "New Report".

Fix direction

Extend the nameChanged guard so name-affecting policy fields force a recompute even when the change is otherwise "badge-only":

Regression 1 → add role
Regression 2 → add fieldList emptiness

Worth fixing these edge cases, similar to approvalMode change what Melvin reported?

…s-skip-name-recompute

TMisiukiewicz · 2026-07-28T08:24:04Z

approvalMode can feed a report name — a badge-only change may leave a name stale

Worth fixing these edge cases, similar to approvalMode change what Melvin reported?

Fixed, though deliberately not with the suggested nameChanged snippet. Folding approvalMode into the blanket check turned out to reintroduce the hang this PR removes: on the first OpenSearchPage, badge fields (and fieldList) genuinely differ between the slim disk policies and the search payload, so any policy-wide name trigger fires for ~all 5.6k policies and recomputes all names again.

Instead, the recompute is scoped to the report shapes that actually read each field: approvalMode/role deltas drop the name skip only for threads (parentReportActionID), and fieldList emptiness flips only for empty-named EXPENSE/IOU reports (the "New Report" fallback). Re-profiled the Spend-tab open to confirm the perf win is intact.

codecov · 2026-07-28T08:31:24Z

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
...bs/actions/OnyxDerived/configs/reportAttributes.ts	`98.68% <100.00%> (+0.92%)`	⬆️
... and 15 files with indirect coverage changes

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ac950abc00

ℹ️ 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 · 2026-07-28T08:53:56Z

+                    const emptyNameChanged = isPolicyFieldListEmpty(prevPolicy ?? undefined) !== isPolicyFieldListEmpty(nextPolicy ?? undefined);
+                    if (!hasPolicyRelevantFieldChanged(prevPolicy, nextPolicy) && !nameChanged && !emptyNameChanged) {


Track non-empty fieldList changes before skipping policies

When policies are seeded from disk and the server later returns a policy whose fieldList changed from one non-empty set to another, this emptiness-only check makes the POLICY trigger look irrelevant and the incremental path returns currentValue. However report attributes call hasVisibleReportFieldViolations(...), which reads the actual policy.fieldList definitions to decide the RBR/Fix badge, so adding/removing/disabling a report field can leave existing expense or invoice reports with stale badges until some unrelated report update happens.

Useful? React with 👍 / 👎.

MelvinBot · 2026-07-28T08:57:24Z

🤖 Regression review — I traced the new "reuse cached name for badge-only policy changes" logic against every policy field the name pipeline reads. Found one real (but narrow) regression; the rest of the mechanics check out.

Regression: a `policy.type` change can leave a stale thread name

hasPolicyRelevantFieldChanged diffs six fields — type, approvalMode, reimbursementChoice, autoReimbursementLimit, role, autoReimbursement.limit. Before this PR, a change to any of them recomputed the name for every report on that policy. Now a report is treated as "badge-only" (name reused) unless a name-affecting disqualifier fires — and threadNameChanged only covers approvalMode/role.

That leaves type unguarded, and type does feed a name: a "policy rules modified" thread message reads arePolicyRulesEnabled(policy) (= isControlPolicy(policy) → policy.type === CORPORATE) to decide whether to render the rules link. So a policy whose only changed relevant field is type (e.g. a Collect↔Control workspace upgrade/downgrade) hits isThreadNameAffected = false, gets pushed to policyBadgeOnlyReportKeys, and keeps its stale cached name — where the pre-PR code recomputed it.

Severity: low. Requires a type transition (rare) on a report with a MODIFIED_EXPENSE/policy-rules parent action, and the name self-heals on the next non-policy update to that report. But it's a behavior change from before, and it's not covered by the PR's tests.

Fix (one line): add type to threadNameChanged:

const threadNameChanged =
    prevPolicy?.approvalMode !== nextPolicy?.approvalMode ||
    prevPolicy?.role !== nextPolicy?.role ||
    prevPolicy?.type !== nextPolicy?.type;

Verified clean (no regression)

What I checked and why it's safe

Other newly-skipped fields — the fields now skipped that weren't before are type, reimbursementChoice, autoReimbursementLimit, autoReimbursement.limit. Only type feeds a name (above). reimbursementChoice/autoReimbursementLimit/autoReimbursement.limit are read nowhere in ReportNameUtils.ts or ModifiedExpenseMessage.ts — genuinely badge-only. ✅
connections / approver / owner / areRulesEnabled — these do feed some thread names (vendor labels, markedAsDone vs submitted, rules-link gating), but none are in hasPolicyRelevantFieldChanged, so a change to them never pulled the report into the recompute pass even before this PR. Pre-existing behavior, not a regression introduced here.
Baseline seeding (L262-264) — the guard !hasKeyTriggeredCompute(POLICY) correctly prevents a real first-flush POLICY change from being masked; previousPolicies is only advanced inside the POLICY branch. Seeding a genuine change is not possible. ✅
Key formats — policyBadgeOnlyReportKeys, the nameSkipKeys deletions, and the loop's key are all report_<id> (via prepareReportKeys), so nameSkipKeys.has(key) and the deletions actually match. ✅
Parent-chat enqueue without delete (L413-414) — safe because any policy whose name changed is excluded from policyBadgeOnlyReportKeys, so a parent workspace chat pulled in by a child update can't skip a real name change. Note this correctness is load-bearing on the nameChanged set (name/achAccount only) — worth a comment so a future name-input addition doesn't silently break it.
cachedName !== undefined fallthrough (L599-600) — a badge-only report with no cached name correctly falls through to computeReportName. ✅

Next Steps: Reply with @MelvinBot <feedback> to refine, or add the type guard above. Confidence: high on the type gap (code-traced end to end); low-to-medium on real-world frequency of type-only policy pushes.

JmillsExpensify

No product review required on this one.

…s-skip-name-recompute

OSBotify · 2026-07-28T18:51:53Z

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

github-actions · 2026-07-28T19:11:01Z

🚧 mountiny has triggered a test Expensify/App build. You can view the workflow run here.

github-actions · 2026-07-28T19:24:54Z

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #97093.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-9e5425a096b-2be666f-9a218e44975b6197eab657581dd540bfccd05bc2/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-9e5425a-2be666f-16f575717b258efe5e8f0b5ffb95a65a49bbbbe8/index.html

Web 🕸️
https://97093.pr-testing.expensify.com

👀 View the workflow run that generated this build 👀

OSBotify · 2026-07-29T21:21:07Z

🚀 Deployed to staging by https://github.com/mountiny in version: 9.4.46-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

MelvinBot · 2026-07-29T21:23:43Z

🤖 Help site review: no docs changes required.

I reviewed the changes in this PR against the help site articles under docs/articles, and no updates are needed.

This is a pure internal performance optimization with no user-facing behavior change. It only affects how the reportAttributes derived value decides whether to recompute a report's name in src/libs/actions/OnyxDerived/configs/reportAttributes.ts — reports whose policy change touched badge-only fields now reuse their cached name instead of running computeReportName. Report names, LHN badges, the Spend tab, and every other visible surface behave exactly the same; they just render faster (the ~30s → ~5s improvement on cold start). Nothing about a documented feature, tab, setting, or workflow changes.

Since there's no behavior change to describe, there's nothing for the help site to document, so I did not create a draft docs PR.

@TMisiukiewicz, please confirm you agree this change has no user-facing impact that the help site would need to document. If you think a help article is affected, let me know which article/behavior and I'll draft the update.

Skip report-name recompute for badge-only policy changes

9b8ba05

melvin-bot Bot assigned TMisiukiewicz Jul 27, 2026

Rename test variable to fix cspell

d816bbb

mountiny mentioned this pull request Jul 27, 2026

Skip report name recompute for badge-only policy changes in reportAttributes #97095

Open

TMisiukiewicz marked this pull request as ready for review July 27, 2026 12:40

TMisiukiewicz requested review from a team as code owners July 27, 2026 12:40

melvin-bot Bot requested review from JmillsExpensify and situchan and removed request for a team July 27, 2026 12:41

melvin-bot Bot removed the request for review from a team July 27, 2026 12:41

chatgpt-codex-connector Bot reviewed Jul 27, 2026

View reviewed changes

Comment thread src/libs/actions/OnyxDerived/configs/reportAttributes.ts Outdated

Comment thread src/libs/actions/OnyxDerived/configs/reportAttributes.ts

TMisiukiewicz added 2 commits July 27, 2026 15:12

Fix stale name on policy rename and receiver-policy change

e20715c

Update test: policy name change now recomputes name

f51a475

situchan reviewed Jul 27, 2026

View reviewed changes

Comment thread src/libs/actions/OnyxDerived/configs/reportAttributes.ts

chatgpt-codex-connector Bot reviewed Jul 27, 2026

View reviewed changes

Comment thread src/libs/actions/OnyxDerived/configs/reportAttributes.ts Outdated

Merge remote-tracking branch 'origin/main' into perf/report-attribute…

389d9eb

…s-skip-name-recompute

Scope policy name-field checks to affected report shapes

edee233

situchan reviewed Jul 28, 2026

View reviewed changes

Comment thread src/libs/actions/OnyxDerived/configs/reportAttributes.ts Outdated

TMisiukiewicz added 2 commits July 28, 2026 10:35

Shorten comments

f51b9c5

Trim redundant comment

ac950ab

situchan approved these changes Jul 28, 2026

View reviewed changes

melvin-bot Bot requested a review from mountiny July 28, 2026 08:47

chatgpt-codex-connector Bot reviewed Jul 28, 2026

View reviewed changes

JmillsExpensify reviewed Jul 28, 2026

View reviewed changes

mountiny requested changes Jul 28, 2026

View reviewed changes

Comment thread src/libs/actions/OnyxDerived/configs/reportAttributes.ts Outdated

TMisiukiewicz added 2 commits July 28, 2026 20:10

Merge remote-tracking branch 'origin/main' into perf/report-attribute…

7c2e310

…s-skip-name-recompute

Rename policyBadgeOnlyReportKeys to nameSkipPolicyReportKeys

a816f81

TMisiukiewicz requested a review from mountiny July 28, 2026 18:15

mountiny approved these changes Jul 28, 2026

View reviewed changes

mountiny merged commit 9e5425a into Expensify:main Jul 28, 2026
33 checks passed

OSBotify mentioned this pull request Jul 29, 2026

Deploy Checklist: New Expensify 2026-07-29 #97375

Open

sumo-slonik mentioned this pull request Jul 30, 2026

Persist reportAttributes recompute baselines so app restarts do not t… #96071

Closed

40 tasks

		const emptyNameChanged = isPolicyFieldListEmpty(prevPolicy ?? undefined) !== isPolicyFieldListEmpty(nextPolicy ?? undefined);
		if (!hasPolicyRelevantFieldChanged(prevPolicy, nextPolicy) && !nameChanged && !emptyNameChanged) {

Uh oh!

Conversation

TMisiukiewicz commented Jul 27, 2026 • edited by mountiny Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

melvin-bot Bot commented Jul 27, 2026

Uh oh!

situchan commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Reviewer Checklist

Screenshots/Videos

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

MelvinBot commented Jul 27, 2026

Review

🟠 approvalMode can feed a report name — a badge-only change may leave a name stale

Uh oh!

situchan commented Jul 27, 2026

Regression Analysis:

Fix direction

Uh oh!

TMisiukiewicz commented Jul 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

codecov Bot commented Jul 28, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Jul 28, 2026

Choose a reason for hiding this comment

Uh oh!

MelvinBot commented Jul 28, 2026

Regression: a policy.type change can leave a stale thread name

Verified clean (no regression)

Uh oh!

JmillsExpensify left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

OSBotify commented Jul 28, 2026

Uh oh!

github-actions Bot commented Jul 28, 2026

Uh oh!

github-actions Bot commented Jul 28, 2026

Uh oh!

OSBotify commented Jul 29, 2026

Uh oh!

MelvinBot commented Jul 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

TMisiukiewicz commented Jul 27, 2026 •

edited by mountiny

Loading

situchan commented Jul 27, 2026 •

edited

Loading

🟠 `approvalMode` can feed a report name — a badge-only change may leave a name stale

TMisiukiewicz commented Jul 28, 2026 •

edited

Loading

codecov Bot commented Jul 28, 2026 •

edited by github-actions Bot

Loading

Regression: a `policy.type` change can leave a stale thread name