[Due for payment 2025-04-18] [Due for payment 2025-04-17] [$250] Update logic with resetSMSDeliveryFailure after updating the backoff block in the BE

[carlosmiceli]

We've recently updated the backend logic for handling SMS delivery failures to use progressive backoff durations instead of a fixed 24-hour block. Along with this change, the resetSMSDeliveryFailureStatus API response now always includes a hasSMSDeliveryFailure boolean to indicate whether the user is still blocked from receiving SMS messages.

The current frontend logic in SMSDeliveryFailurePage checksaccount?.smsDeliveryFailureStatus as a truthy object and also depends on a field called isReset. The resetSMSDeliveryFailureStatus response does not include an isReset field, so not sure where it's coming from. We need to rely solely on hasSMSDeliveryFailure to block the user from signing in or not. If it resets successfully, make sure to not automatically trigger SMS sending upon reset success. The user should explicitly click to send the code again with smsDeliveryFailurePage.validationSuccess

Successful reset (user is no longer blocked):

{
  "hasSMSDeliveryFailure": false
}

Failed reset (user still blocked):

{
  "hasSMSDeliveryFailure": true,
  "message": {
    "days": 1,
    "hours": 2,
    "minutes": 30
  }
}

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021903286530651681051
• Upwork Job ID: 1903286530651681051
• Last Price Increase: 2025-03-22
• Automatic offers:
• suneox | Reviewer | 106654064

Issue Owner

Current Issue Owner: @alexpensify

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021903286530651681051

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @suneox (External)

[rushatgabhane]

🚨 Edited by proposal-police: This proposal was edited at 2025-03-22 04:07:53 UTC.

Proposal

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

Update the logic to remove isReset field

What is the root cause of that problem?

The frontend logic is outdated and relies on a non-existent isReset field.

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

Remove the isReset field from the frontend logic. Then the logic will rely solely on the hasSMSDeliveryFailure field to determine whether the user is blocked from receiving SMS messages.

App/src/pages/signin/SMSDeliveryFailurePage.tsx

Line 48 in 2739a5f

const isReset = account?.smsDeliveryFailureStatus?.isReset;

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N.A.

What alternative solutions did you explore? (Optional)

N.A.

[github-actions]

⚠️ Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[Alqatrony]

🧠 Proposal

📌 Problem Statement

The SMS delivery failure handling in the Expensify app needs to be updated.
Currently, the SMSDeliveryFailurePage component uses outdated logic that doesn't align with the recent backend changes.

• It relies on the isReset field, which no longer exists in the API response.
• It misinterprets the new structure, which uses hasSMSDeliveryFailure as the main indicator of whether a user is blocked.
• It also automatically triggers SMS sending after a reset — which is no longer the expected behavior.

---

🧨 Root Cause

The issue originates from a disconnect between frontend and backend implementations.

• Previously, the backend used a fixed 24-hour block for SMS failures.
• It now uses progressive backoff durations (e.g., 5 min, 30 min, 1h).
• The API now returns a simplified response with only a hasSMSDeliveryFailure flag.
• However, the frontend still expects fields like isReset, leading to incorrect behavior and UX issues.

---

🔧 Proposed Solution

Update the SMSDeliveryFailurePage component to:

1. ❌ Remove usage of isReset — it's no longer present.
2. ✅ Rely only on hasSMSDeliveryFailure to determine block state.
3. 🧠 Parse and display countdown messages correctly, based on the updated format (object or string).
4. ✋ Avoid automatic SMS sending after a reset; the user should click manually.
5. 🚦 Differentiate clearly between states:
   • Initial state (loading)
   • Blocked state (countdown)
   • Reset success state (ready to send again)
6. ✅ Update validation success screen logic to only show when the reset is complete and the user is no longer blocked.

---

🧪 Test Coverage Suggestions

✅ Blocked User (hasSMSDeliveryFailure = true)

• Displays the correct error and countdown timer.
• User cannot request a new SMS code.
• "Confirm" button clears sign-in data properly.

✅ Reset Successful (hasSMSDeliveryFailure = false)

• Displays success message.
• No SMS is automatically sent.
• "Send" button is enabled for manual request.
• Clicking "Send" triggers correct action.

✅ Initial Load

• Validate button triggers reset logic.
• Loading indicators appear during validation.

🧵 Message Parsing Edge Cases

• Handles both string and object formats for message.
• Correctly shows different time units (minutes, hours, days).
• Handles missing time gracefully.

---

💡 Alternative Solutions (Explored)

• Option 1: Maintain isReset temporarily for backward compatibility.

  • ❌ Adds unnecessary complexity and technical debt.

• Option 2: Build a new component from scratch using the new structure.

  • ❌ Duplicates logic and increases migration complexity.

✅ Preferred Option:
Update the current component to reflect the new backend logic. This is the cleanest, most maintainable, and least disruptive path forward.

Contributor details
Your Expensify account email: ali.alqatrony@hotmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~0178ff1ba8882aeb12

---

[melvin-bot]

📣 @Alqatrony! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[suneox]

@Alqatrony Welcome to Expensify! First, please take some time to read through the guidelines on how to contribute to this project. This will help you understand the process and expectations for contributing effectively.

[Alqatrony]

Appreciate the warm welcome, @suneox! I've read the contributing guidelines and I'm excited to be part of the project!