26W5 - Subscription - "Auto-renew" is enabled by default

[lanitochka17]

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: v9.3.11-15
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-3932/folder/13176687/41236709/1159241277?sort=-status_id
Email or phone of affected tester (no customers): gocemate+b21549004a@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 10/Chrome
App Component: Other

Action Performed:

1. Sign in with an existing account which has workspace created before April 1, 2025
2. Click Account > Subscription
3. Click the "Subscription settings"
4. Verify "Annual subscription" is selected by default
5. Check "Auto-renew" section
   Verify toggle switch for "Auto-renew" and its disabled by default

Expected Result:

"Auto-renew" option should be disabled by default

Actual Result:

"Auto-renew" is enabled by default

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7062053_1769788744559.Recording__187.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @joekaufmanexpensify

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @joekaufmanexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-01-30 16:37:52 UTC.

Proposal

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

When a user signs into an existing account that has a workspace created before April 1, 2025, navigates to Account > Subscription > Subscription settings, the "Auto-renew" toggle appears enabled by default. The expected behavior according to the regression test is that the toggle should be disabled by default.

What is the root cause of that problem?

The root cause is in the usePrivateSubscription hook, which applies a fallback value of true when the backend does not include the autoRenew field in the NVP_PRIVATE_SUBSCRIPTION data. For pre-April 2025 accounts, the backend does not return an explicit autoRenew value in the subscription payload, so the field arrives as undefined. The hook then applies the ?? true nullish coalescing, which forces the toggle to display as enabled even though the user never opted in to auto-renewal.

App/src/hooks/usePrivateSubscription.ts

Lines 12 to 16 in 80dc863

	return privateSubscription
	? {
	...privateSubscription,
	autoRenew: privateSubscription.autoRenew ?? true,
	}

This hook is consumed in the SubscriptionSettings page where it directly drives the toggle's isActive prop, causing the toggle to appear enabled.

App/src/pages/settings/Subscription/SubscriptionSettings/index.tsx

Line 239 in 80dc863

isActive={privateSubscription?.autoRenew}

It is also consumed in SubscriptionPlanCardActionButton where it determines the auto-renew display text in the subscription summary.

App/src/pages/settings/Subscription/SubscriptionPlan/SubscriptionPlanCardActionButton.tsx

Line 138 in 80dc863

const autoRenew = privateSubscription?.autoRenew ? translate('subscription.subscriptionSettings.on') : translate('subscription.subscriptionSettings.off');

The ?? true default was introduced in PR #67473 (merged via commit c2ea489082e) to fix issue #66168, where the auto-renew toggle appeared disabled for newly upgraded Control plan accounts. At that time, a backend engineer confirmed that the backend treats a missing autoRenew key as enabled. However, the regression test for the current issue specifically expects the toggle to be disabled by default for pre-existing accounts, indicating the expected behavior has since been updated so that auto-renew should not appear enabled unless the backend explicitly sends autoRenew: true.

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

We should change the fallback value in the usePrivateSubscription hook from true to false. This is a single-character change in one file. When the backend explicitly sends autoRenew: true (for accounts that have it enabled), the ?? operator will not apply and the value will correctly remain true. When the backend does not include the field (for pre-April 2025 accounts that never explicitly set it), the toggle will correctly display as disabled.

App/src/hooks/usePrivateSubscription.ts

Line 15 in 80dc863

autoRenew: privateSubscription.autoRenew ?? true,

The line should change from autoRenew: privateSubscription.autoRenew ?? true to autoRenew: privateSubscription.autoRenew ?? false. This is the minimal fix because the usePrivateSubscription hook is already the centralized place where all subscription consumers get the autoRenew value, so changing it here automatically fixes every downstream consumer (the toggle in SubscriptionSettings, the summary text in SubscriptionPlanCardActionButton, and any other current or future consumers of the hook).

What alternative solutions did you explore? (Optional)

N/A

[yatin-italy]

Proposal

Restate the problem this issue is trying to solve.

The Auto-renew toggle in Subscription settings shows as enabled by default for accounts where the workspace was created before 2025-04-01. This is wrong. The toggle should be disabled by default when there is no autoRenew value from the server.

What is the root cause of that problem?

The earliest wrong assumption is in src/hooks/usePrivateSubscription.ts inside the usePrivateSubscription hook, where missing autoRenew is forced to true. The code assumes that if autoRenew is undefined, it should default to enabled. This is wrong because older accounts do not have this field, and treating missing data as true directly causes the UI to render the toggle as enabled.

File: src/hooks/usePrivateSubscription.ts
Function: usePrivateSubscription
Lines 12-16:

return privateSubscription
    ? {
          ...privateSubscription,
          autoRenew: privateSubscription.autoRenew ?? true,
      }
    : undefined;

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

Make a defensive default at the render site so a missing autoRenew shows as disabled.

Apply a one-line change in the settings UI.

File: src/pages/settings/Subscription/SubscriptionSettings/index.tsx
Current code (Lines 232-239):

<OfflineWithFeedback pendingAction={privateSubscription?.pendingFields?.autoRenew}>
    <View style={styles.mt5}>
        <ToggleSettingOptionRow
            title={translate('subscription.subscriptionSettings.autoRenew')}
            switchAccessibilityLabel={translate('subscription.subscriptionSettings.autoRenew')}
            onToggle={handleAutoRenewToggle}
            isActive={privateSubscription?.autoRenew}
        />

Change to:

isActive={privateSubscription?.autoRenew ?? false}

This matches the existing pattern used for other toggles in the same file.

What alternative solutions did you explore? (Optional)

Changing the default in src/hooks/usePrivateSubscription.ts was considered but not chosen because it affects shared data logic and increases risk. The UI-level default is smaller and safer.

[cosmicvulpes]

Proposal

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

When a user signs in with an existing account that has a workspace created before April 1, 2025, and navigates to Account > Subscription > Subscription settings, the "Auto-renew" toggle is enabled by default. According to the regression test, the expected behavior is that the toggle should be disabled by default for such accounts.

What is the root cause of that problem?

The root cause is in the usePrivateSubscription hook, which applies a fallback value of true when the backend does not include the autoRenew field in the NVP_PRIVATE_SUBSCRIPTION data.

https://github.com/Expensify/App/blob/eb7deee963f1084ff0a950d0b1a93d4a423edd21/src/hooks/usePrivateSubscription.ts#L12-L17

For pre-April 2025 accounts, the backend does not return an explicit autoRenew value in the subscription payload, so the field arrives as undefined. The hook then applies the ?? true nullish coalescing fallback, which forces the toggle to display as enabled even though the user never explicitly opted in to auto-renewal.

This hook is consumed in SubscriptionSettings where the autoRenew value directly drives the toggle's isActive prop:

https://github.com/Expensify/App/blob/eb7deee963f1084ff0a950d0b1a93d4a423edd21/src/pages/settings/Subscription/SubscriptionSettings/index.tsx#L239

It is also consumed in SubscriptionPlanCardActionButton where it determines the auto-renew display text:

https://github.com/Expensify/App/blob/eb7deee963f1084ff0a950d0b1a93d4a423edd21/src/pages/settings/Subscription/SubscriptionPlan/SubscriptionPlanCardActionButton.tsx#L138

The ?? true default was introduced in PR #67473 (commit c2ea489082e) to fix issue #66168, where the auto-renew toggle appeared disabled for newly upgraded Control plan accounts. At that time, the expectation was that auto-renew should default to enabled. However, the current regression test specifically expects the toggle to be disabled by default for pre-existing accounts (workspaces created before April 1, 2025), indicating the expected behavior has changed.

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

Change the fallback value in the usePrivateSubscription hook from true to false:

autoRenew: privateSubscription.autoRenew ?? false,

This is a single-character change in src/hooks/usePrivateSubscription.ts at line 15. When the backend explicitly sends autoRenew: true, the ?? operator will not apply and the value will correctly remain true. When the backend does not include the field (for pre-April 2025 accounts that never explicitly set it), the toggle will correctly display as disabled.

This is the minimal and correct fix because the usePrivateSubscription hook is the centralized place where all subscription consumers get the autoRenew value, so changing it here automatically fixes every downstream consumer (the toggle in SubscriptionSettings, the summary text in SubscriptionPlanCardActionButton, and any other current or future consumers).

What alternative solutions did you explore? (Optional)

N/A

[joekaufmanexpensify]

@lanitochka17 could you share where this test originated from, ie what prompted it to be added to browserstack? It seems like it was added recently. The expected behavior doesn't seem correct to me, so I am interested to understand more about where it originated.

[PiyushChandra17]

Proposal

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

26W5 - Subscription - "Auto-renew" is enabled by default

What is the root cause of that problem?

The root cause is that by default, we are setting the autoRenew to true here

App/src/hooks/usePrivateSubscription.ts

Line 15 in f745547

autoRenew: privateSubscription.autoRenew ?? true,

App/src/pages/settings/Subscription/SubscriptionSettings/index.tsx

Line 239 in c467236

isActive={privateSubscription?.autoRenew}

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

• Set this autoRenew here to false

App/src/hooks/usePrivateSubscription.ts

Lines 12 to 17 in f745547

	return privateSubscription
	? {
	...privateSubscription,
	autoRenew: privateSubscription.autoRenew ?? true,
	}
	: undefined;

autoRenew: privateSubscription.autoRenew ?? false

What alternative solutions did you explore? (Optional)

Result:

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[github-actions]

⚠️ @PiyushChandra17 Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.