[Due for payment 2026-07-23] "Enjoying New Expensify" modal cannot be dismissed — dismisses then immediately reappears

[melvin-bot]

Coming from https://expensify.slack.com/archives/C03SSAQ7P/p1784131189506799

Description

The "Enjoying New Expensify" modal cannot be dismissed. When a user closes it, it dismisses and then immediately reappears, making it impossible to get past it.

This was surfaced when investigating an issue with Supportal — the root cause is the modal blocking all interaction, not Supportal itself.

Reproducible on

• Production
• Staging

Impact

Users (including support staff) are unable to access account content due to the modal blocking the UI and reappearing after dismissal.

Notes

Believed to be a regression introduced in a recent pull request.

[melvin-bot]

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

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

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #94936 - "Allow negative response to be reprompted after 30 days" by @hungvu193 (High confidence)
Related Issues: Part of https://github.com/Expensify/Expensify/issues/635692

Recommendation: REVERT

PR #94936 loosened the suppression guard for the "Enjoying New Expensify?" (proactiveAppReview) modal so it now only stays hidden for a positive response, delegating suppression of negative/skip responses to a 30-day lastPrompt check that does not reliably evaluate — so the modal re-shows immediately after dismissal. Reverting cleanly restores the previous "hide on any definitive response" behavior; the "reprompt after 30 days" feature can be re-landed with a correct date check.

Assigned: @hungvu193 (PR author), @MariaHCD (approving reviewer)
Labels: No label changes. This is a Frontend bug (an App PR caused it), so DeployBlockerCash correctly remains — the App deploy is blocked.

📋 Detailed Analysis

Evidence

• The modal text "Enjoying New Expensify?" comes from the proactiveAppReview translation key, rendered by ProactiveAppReviewModal and driven by ProactiveAppReviewModalManager / useProactiveAppReview.
• PR Allow negative response to be reprompted after 30 days #94936 (merged 2026-07-13, included in the current 9.4.34-12 staging release, Deploy Checklist: New Expensify 2026-07-14 #96044) modifies exactly these files: src/hooks/useProactiveAppReview.ts, src/components/ProactiveAppReviewModalManager.tsx, and src/libs/actions/User.ts.
• The bug is staging-only, consistent with a PR that is on staging but not yet on production.
• The PR's own QA steps (choose "Not Really" → verify the modal is dismissed and does not show again) are exactly the flow that is now broken.

Verification

• Affected files confirmed touched by the PR: useProactiveAppReview.ts, ProactiveAppReviewModalManager.tsx, User.ts.
• The key behavioral change is in the reprompt guard in useProactiveAppReview.ts.

Root Cause

Before the PR, the modal was suppressed for any definitive response:

// Only allow re-prompting if they skipped
if (proactiveAppReview.response && proactiveAppReview.response !== 'skip') {
    return false;
}

After the PR, it is suppressed only for positive:

// Don't show again after user gave a positive response
if (proactiveAppReview.response && proactiveAppReview.response === 'positive') {
    return false;
}

This intentionally removes negative (and skip) from the "always hide" set, so those responses now rely entirely on the 30-day lastPrompt window to stay hidden:

const lastPromptTime = new Date(proactiveAppReview.lastPrompt).getTime();
const now = Date.now();
const daysSinceLastPrompt = (now - lastPromptTime) / THIRTY_DAYS_IN_MS;
if (daysSinceLastPrompt < 1) {
    return false;
}

On dismissal, respondToProactiveAppReview optimistically writes lastPrompt: DateUtils.getDBTime(), and getDBTime returns a UTC wall-clock string with the timezone designator stripped (e.g. "2026-07-15 18:30:00.000", the Z is removed). Parsing that space-separated, timezone-less string with new Date(...) is not reliable across JS engines (it is parsed as local time, or as Invalid Date → NaN). When it evaluates to NaN, daysSinceLastPrompt is NaN, and NaN < 1 is false, so the guard does not return false.

Net effect: after a user dismisses the modal, shouldShowModal stays true, the latch-open logic in ProactiveAppReviewModalManager re-opens it, and the modal reappears immediately — blocking all interaction (which is what surfaced during the Supportal investigation).

Suggested fix if rolling forward instead of reverting

• Parse lastPrompt as UTC (append Z/T or use the existing DateUtils helpers) so the 30-day window is evaluated correctly, and
• Rename/fix the daysSinceLastPrompt computation so the variable name matches the 30-day divisor it actually uses.