Travel - "Please add a work email as your primary login to book travel" blocks users who already have a work email

[MelvinBot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: Not captured at report time — confirmed present in main as of 9956186
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: N/A — reported by a customer and reproduced internally
Email or phone of affected tester (no customers): sheena@expensifail.com
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL: https://github.com/Expensify/Expensify/issues/680367
Issue reported by: Applause / Guide (internal report)
Slack conversation (hyperlinked to channel name): Slack

Action Performed:

1. Sign in to New Expensify with an account whose primary login is a work email (not a phone number, not a public domain).
2. Hard-reload the app, so the session is restored from storage rather than from a fresh sign-in response. (account.primaryLogin is now absent from Onyx — confirm in the Onyx debug view.)
3. Open a workspace → Travel.
4. Press the travel button ("Get started" / "Book travel").

Expected Result:

Travel enablement proceeds. The user already has a work email as their primary login, so no contact-method error should appear.

Actual Result:

The inline error "Please add a work email as your primary login to book travel." renders below the button and travel enablement is blocked.

The message is misleading: this branch does not check the email domain at all. It is the travel.phoneError string, guarded by a condition that means "primary login is missing or is a phone number".

Workaround:

Yes — the user can enable and use Travel from Expensify Classic, which has no equivalent client-side guard. Reloading the page can also clear it once a code path repopulates account.primaryLogin, which is why the failure looks intermittent. The customer has been informed of the Classic workaround.

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

The guard is platform-agnostic client logic, so it is expected to reproduce on every platform. Only web was verified.

Screenshots/Videos

---

Root cause

Two things combine. The first is entirely in this repo.

1. The fallback in BookTravelButton is dead code.

src/components/BookTravelButton.tsx:71 and :78:

const primaryLogin = account?.primaryLogin ?? '';
// ...
const primaryContactMethod = primaryLogin ?? sessionEmail ?? '';

primaryLogin has already been defaulted to ''. Because '' is not nullish, ?? sessionEmail ?? '' never evaluates — the intended fallback to the session email is unreachable.

2. account.primaryLogin is not always present in Onyx.

Account.primaryLogin is correctly typed optional in src/types/onyx/Account.ts. Within App it is written only by sign-in responses, by setContactMethodAsDefault in src/libs/actions/User.ts, and by the HybridApp delegate path in src/libs/actions/Session/index.ts. The app-init payload does not populate it, so any session that reaches the Travel page without one of those writes — a reload, a session restored from storage, a copilot switch, a new or unvalidated account — has it undefined.

Result: the guard at src/components/BookTravelButton.tsx:139 reads '', takes the !primaryContactMethod branch, and renders the error. Str.isSMSLogin('') is false, so this is unambiguously the empty-value branch, not real SMS-login detection. That explains every symptom: per-session and intermittent, hits users with confirmed work emails, and Classic is unaffected because it has no equivalent guard.

Note the same empty string also flows into the public-domain check at :146, so that branch is evaluating against no data either.

Proposed fix

Replace both lines with the existing hook, usePrimaryContactMethod(), which returns exactly the fallback this code was trying to express:

return account?.primaryLogin ?? sessionEmail ?? '';

Several card and validate-code pages already use it, so this makes travel consistent with the rest of the app and lets the two useOnyx calls in BookTravelButton be dropped.

Two follow-ups worth doing in the same pass:

• Copy. travel.phoneError says "add a work email as your primary login", but the condition it guards is "primary login is a phone number". Nothing about it checks the domain — the actual public-domain check is a separate branch that navigates to a full error page. The wording should describe the SMS-login case, so this class of bug is not misdiagnosed as a domain problem again.
• Backend, defense in depth. Returning primaryLogin in the app-init account payload would close the underlying data gap; the session-email fallback is a client-side patch over missing data. This part is tracked internally in Expensify/Expensify#680367 and is out of scope for this issue.

Open question for travel engineering: is there a reason this guard reads account.primaryLogin directly rather than the session email? Spotnana needs a real mailbox for booking confirmations, and the session email should always be one — but if there is a case where the session email is a phone number while the primary login is not, the check must stay on primaryLogin and the backend change becomes the required path.

Slack thread: https://expensify.slack.com/archives/C0BCEQ2UNSG/p1788992380267439

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @daledah

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[melvin-bot]

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

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[Sterlingii]

This user is having the same issue. mirvin@spreporting.com getting Travel enabled https://github.com/Expensify/Expensify/issues/678629

[melvin-bot]

📣 @Sterlingii! 📣
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>

[daledah]

@MelvinBot please open the draft PR for this issue

[MelvinBot]

🤖 Draft PR created: #100931

Please mark it as "Ready for review" when it is ready for review.

What changed: src/components/BookTravelButton.tsx:74 now uses the existing usePrimaryContactMethod() hook instead of the two dead-code lines, so the session-email fallback actually runs when account.primaryLogin is absent. The two now-unused useOnyx calls were dropped. I also added a regression test at tests/unit/components/BookTravelButtonTest.tsx:331-353 — it fails on main and passes with the fix, which confirms the root cause in the issue body.

Scoped out, deliberately: the travel.phoneError copy rewrite. Once this fix lands, that string only renders for genuine SMS logins, where "add a work email as your primary login" is accurate — so it is no longer load-bearing for this bug, and rewording it needs translations across all 12 locales plus marketing sign-off. The backend app-init payload change is tracked internally, as the issue notes.

Tests run locally

Check	Result
npm run typecheck	✅ passed (all 5 tsconfig projects)
npm test -- tests/unit/components/BookTravelButtonTest.tsx	✅ 12/12 passed
npm test -- --testPathPattern "[Tt]ravel"	✅ 13 suites / 151 tests passed
npm run spell-changed	✅ 0 issues in 2 files
npm run react-compiler-compliance-check -- check src/components/BookTravelButton.tsx	✅ no violations reported
npx eslint <changed files>	⚠️ could not run — the sandbox caps Node's heap at 4 GB and ESLint OOMs before reporting. CI will cover it.
npm run prettier	⚠️ not applicable — this repo has no prettier script or Prettier config; formatting is enforced through ESLint.

I could not verify this in a browser. Web prep failed in this run (no dev SSL cert), so NewDot could not be driven interactively. The evidence above is static analysis plus the unit tests. The manual reproduction steps from the issue still need a human pass before this goes out of draft — I left them as a starting point in the PR's Tests section for you to confirm and fill in, along with the QA steps.

---

Next Steps: Reply with @MelvinBot <your feedback> if you want the implementation adjusted.