[$250] Web - Help site - Send a message button open error page

[applause-bot]

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.4.29-0
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
Email or phone of affected tester (no customers): leungbratt6+08071@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 10/Chrome
App Component: User Settings

Action Performed:

1. Open the NewDot app
2. Navigate to the Account
3. Click on Help -> Help site
4. Scroll down and click on the Send a message button

Expected Result:

Can open a chat or email box to the help site

Actual Result:

Error page open: " This site can’t be reached
Check if there is a typo in dev.new.expensify.com.

If spelling is correct, try running Windows Network Diagnostics.
DNS_PROBE_FINISHED_NXDOMAIN"

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7202908_1783520061201.help_send.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Murugesan Natarajan
Bug ID: 7202908

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022074862243424959975
• Upwork Job ID: 2074862243424959975
• Last Price Increase: 2026-07-08

Issue Owner

Current Issue Owner: @lorretheboy

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/c6e4c01e79756064f9a6e77ba0a5358f0add07a71e111e411dbc3089a82a4ca9

[MelvinBot]

Proposal

What is the root cause of that problem?

The help site's "Send a message" button links to a URL that is chosen based on the Jekyll build environment, but the live help site is built as development, so it points at the dev domain.

In docs/_includes/CONST.html:1-5, MAIN_SITE_URL is https://new.expensify.com only when jekyll.environment == "production", otherwise it falls back to https://dev.new.expensify.com:8082. The button in docs/_layouts/default.html:114 uses CONCIERGE_CHAT_URL = {{MAIN_SITE_URL}}/concierge.

The deploy workflow builds Jekyll without setting JEKYLL_ENV, so Jekyll defaults to development and the button resolves to https://dev.new.expensify.com:8082/concierge — a non-existent domain, producing DNS_PROBE_FINISHED_NXDOMAIN. See the build step at deployExpensifyHelp.yml:68 — JEKYLL_ENV is set nowhere in the repo.

Investigation details & evidence

• grep -rn "JEKYLL_ENV" across the repo returns no matches — the variable is never set for the production/staging help-site build.
• bundle exec jekyll build with no JEKYLL_ENV uses Jekyll's default environment development, so the {% else %} branch in CONST.html is always taken on the deployed site.
• This matches the report exactly: reproducible in both staging and production, error domain is dev.new.expensify.com.
• Same MAIN_SITE_URL fallback affects any other help-site link built from it (e.g. CONCIERGE_CHAT_URL), so a single build-env fix covers all of them.

Alternative considered: flip the default in CONST.html so production is the fallback and dev requires the flag. Rejected — the conditional is written intentionally around production; the real defect is that the production build never sets the environment, so fixing the build is the correct, lower-risk change.

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

Set the Jekyll environment to production on the Build Jekyll site step of deployExpensifyHelp.yml (add JEKYLL_ENV: production to that step's env). This makes CONST.html resolve MAIN_SITE_URL to https://new.expensify.com, so the "Send a message" button links to https://new.expensify.com/concierge.

Confidence: High — code evidence fully explains the symptom and the affected domain.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/95607) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[dilshodmackbook-sketch]

Proposal

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

On the production help site (help.expensify.com), clicking the Send a message button at the bottom of a page navigates to https://dev.new.expensify.com:8082/concierge, which is an unreachable dev URL and shows DNS_PROBE_FINISHED_NXDOMAIN. It should open Concierge at https://new.expensify.com/concierge.

What is the root cause of that problem?

The button's href is CONCIERGE_CHAT_URL, which is derived from MAIN_SITE_URL. That value is chosen based on jekyll.environment:

App/docs/_includes/CONST.html

Lines 1 to 7 in fcf80bb

	{% if jekyll.environment == "production" %}
	{% assign MAIN_SITE_URL = "https://new.expensify.com" %}
	{% else %}
	{% assign MAIN_SITE_URL = "https://dev.new.expensify.com:8082" %}
	{% endif %}
	{% capture CONCIERGE_CHAT_URL %}{{MAIN_SITE_URL}}/concierge{% endcapture %}

App/docs/_layouts/default.html

Lines 114 to 118 in fcf80bb

	<a href="{{ CONCIERGE_CHAT_URL }}" target="_blank">
	<div class="submit-button">
	<button class="success">Send a message</button>
	</div>
	</a>

Only when jekyll.environment == "production" does it use https://new.expensify.com; otherwise it falls back to https://dev.new.expensify.com:8082.

jekyll.environment is populated from the JEKYLL_ENV environment variable and defaults to "development" when that variable is unset. The deploy workflow builds the site without ever setting JEKYLL_ENV:

App/.github/workflows/deployExpensifyHelp.yml

Lines 68 to 70 in fcf80bb

	- name: Build Jekyll site
	run: bundle exec jekyll build --source ./ --destination ./_site
	working-directory: ./docs

So the production help.expensify.com build resolves jekyll.environment to development, MAIN_SITE_URL becomes the dev URL, and the Concierge link is broken.

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

Set JEKYLL_ENV=production for the "Build Jekyll site" step in .github/workflows/deployExpensifyHelp.yml so the production build resolves jekyll.environment to production:

- name: Build Jekyll site
  env:
      JEKYLL_ENV: production
  run: bundle exec jekyll build --source ./ --destination ./_site
  working-directory: ./docs

With this set, CONST.html picks MAIN_SITE_URL = https://new.expensify.com and the Send a message button correctly points to https://new.expensify.com/concierge.

What specific scenarios should we cover in automated tests to prevent this problem from happening again?

This is a build/CI configuration fix, so it isn't covered by the app's Jest suite. To validate, after the workflow runs we can confirm the deployed CONCIERGE_CHAT_URL in the built page resolves to https://new.expensify.com/concierge (e.g. inspect the generated _site output or the rendered button href on help.expensify.com). We could optionally add a post-build assertion step that greps the generated _site for dev.new.expensify.com and fails if any production-facing link still contains it.

What alternative solutions did you explore? (Optional)

We could instead invert the default in CONST.html so MAIN_SITE_URL defaults to https://new.expensify.com and only uses the dev URL when jekyll.environment == "development". On its own this masks the real misconfiguration (the deploy never sets JEKYLL_ENV) and leaves other environment-gated behavior running in the wrong mode, so I'd keep JEKYLL_ENV: production as the primary fix. It does work well as a defense-in-depth complement, though — with it, even a future env misconfiguration can't ship a dead dev.new.expensify.com link to users.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-08 14:26:20 UTC.

Proposal

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

The "Send a message" button in the "Didn't find what you were looking for?" footer of every help.expensify.com page links to https://dev.new.expensify.com:8082/concierge — a developer-only host that doesn't resolve publicly — so users get a DNS_PROBE_FINISHED_NXDOMAIN error page instead of their Concierge chat.

What is the root cause of that problem?

The deployed help-site HTML is baked with the dev URL at build time because the CI deploy never declares a build environment. The chain:

1. The button's href is {{ CONCIERGE_CHAT_URL }}, rendered in the shared layout that wraps every help article:

   App/docs/_layouts/default.html

   Lines 110 to 118 in d60639b

   	{% include CONST.html %}
   	<div class="get-help">
   	<h2 class="title with-margin">Didn't find what you were looking for?</h2>
   	<p class="description">Concierge is here to answer all your questions.</p>
   	<a href="{{ CONCIERGE_CHAT_URL }}" target="_blank">
   	<div class="submit-button">
   	<button class="success">Send a message</button>
   	</div>
   	</a>

2. CONCIERGE_CHAT_URL is built from MAIN_SITE_URL, which resolves to https://dev.new.expensify.com:8082 unless jekyll.environment == "production":

   App/docs/_includes/CONST.html

   Lines 1 to 7 in d60639b

   	{% if jekyll.environment == "production" %}
   	{% assign MAIN_SITE_URL = "https://new.expensify.com" %}
   	{% else %}
   	{% assign MAIN_SITE_URL = "https://dev.new.expensify.com:8082" %}
   	{% endif %}
   	{% capture CONCIERGE_CHAT_URL %}{{MAIN_SITE_URL}}/concierge{% endcapture %}

3. Jekyll populates jekyll.environment from the JEKYLL_ENV environment variable and defaults it to "development" when unset — for jekyll build as well as jekyll serve.
4. The deploy workflow's build step runs bundle exec jekyll build with no env: block, so every deployed build takes the else branch and bakes the dev URL into the static HTML that Cloudflare Pages serves:

   App/.github/workflows/deployExpensifyHelp.yml

   Lines 68 to 70 in d60639b

   	- name: Build Jekyll site
   	run: bundle exec jekyll build --source ./ --destination ./_site
   	working-directory: ./docs

Structural cause: the pipeline that produces the production artifact never states which environment it is building, and the template's fallback is the dev host. This explains every symptom detail: it reproduces on both staging and production (help.expensify.com is a single static deployment reached from the app in every environment), it is browser-only (the button lives on the external Jekyll site, not in the RN app), and the error names exactly dev.new.expensify.com (Chrome's DNS page shows the host without the :8082 port).

Affected paths (all of them): CONCIERGE_CHAT_URL has exactly one consumer — the footer button in docs/_layouts/default.html (which renders on every article page, so the bug appears site-wide) — and MAIN_SITE_URL has no other consumers anywhere in docs/ or .github/ (verified by grep). deployExpensifyHelp.yml is the only workflow that runs jekyll build; the second help workflow that existed earlier this year (deployNewHelp.yml) has since been deleted, so a single-step fix now covers the entire surface.

History (why this is back): this is the same defect as #89309, where this exact root cause was C+-approved. Neither fix PR ever merged: #90243 (the workflow env: addition) was closed because the bot author's token lacked the workflow scope needed to push workflow-file changes, and its successor #90725 ended up containing only a template-side flip (which is inert — see below), stalled on failing tests, and was closed on 2026-06-19. The deployed site was therefore never rebuilt with a production environment, and the bug resurfaced here.

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

Add JEKYLL_ENV: production to the "Build Jekyll site" step of the deploy workflow (

App/.github/workflows/deployExpensifyHelp.yml

Lines 68 to 70 in d60639b

	- name: Build Jekyll site
	run: bundle exec jekyll build --source ./ --destination ./_site
	working-directory: ./docs

):

      - name: Build Jekyll site
        run: bundle exec jekyll build --source ./ --destination ./_site
        working-directory: ./docs
        env:
          JEKYLL_ENV: production

With that, jekyll.environment == "production" is true in every deployed build, MAIN_SITE_URL resolves to https://new.expensify.com, and the baked button href becomes https://new.expensify.com/concierge — signed-in users land on their Concierge DM, signed-out users hit the sign-in flow first. Since the workflow also builds PR previews, preview deployments will link to production Concierge too, which is what QA needs (those links were dead before). Regression safety in one sentence: local development (bundle exec jekyll serve per docs/README.md) doesn't run this workflow, so the intentional dev-URL behavior for local testing is untouched, and nothing else in the repo reads JEKYLL_ENV.

Why the obvious spot-fix does not work: the tempting template-only fix — flipping the conditional so production is the default branch (exactly what the closed PR #90725 shipped) — is a no-op in CI, because Jekyll defaults jekyll.environment to "development" when JEKYLL_ENV is unset; the flipped check jekyll.environment == "development" still evaluates true during the un-parameterized jekyll build, and the dev URL still gets baked. The prior review reached the same conclusion ("the CONST.html change is correct but inert without it — both must land together"). Hardcoding https://new.expensify.com in CONST.html is also wrong: the dev URL was added deliberately so the locally-served help site points at a local NewDot on :8082, and hardcoding would silently break that intended flow. The environment has to be declared where the production artifact is actually built — the workflow step.

What alternative solutions did you explore? (Optional)

1. Flip the CONST.html conditional (per #90725) — inert on its own for the reason above; it can optionally land alongside the env: change as documentation of intent, but adds nothing functionally.
2. Hardcode the production URL / delete the conditional — fixes the symptom but removes the intentional local-development behavior.
3. Make the dev URL opt-in via a custom env value (e.g. only when JEKYLL_ENV=dev, plus a docs/README.md update) — makes production the true default without touching workflows, but changes every contributor's local flow and deviates from the standard Jekyll JEKYLL_ENV=production convention that reviewers already approved in #89309.

[lorretheboy]

Proposal

What is the root cause of that problem?

The help site's "Send a message" button links to CONCIERGE_CHAT_URL, which is built from MAIN_SITE_URL — and that only points to https://new.expensify.com when Jekyll runs with jekyll.environment == "production"; otherwise it falls back to the local dev URL https://dev.new.expensify.com:8082:

App/docs/_includes/CONST.html

Lines 1 to 7 in 374dbdc

	{% if jekyll.environment == "production" %}
	{% assign MAIN_SITE_URL = "https://new.expensify.com" %}
	{% else %}
	{% assign MAIN_SITE_URL = "https://dev.new.expensify.com:8082" %}
	{% endif %}
	{% capture CONCIERGE_CHAT_URL %}{{MAIN_SITE_URL}}/concierge{% endcapture %}

App/docs/_layouts/default.html

Lines 109 to 119 in 374dbdc

	<!-- Concierge button at the bottom of the page -->
	{% include CONST.html %}
	<div class="get-help">
	<h2 class="title with-margin">Didn't find what you were looking for?</h2>
	<p class="description">Concierge is here to answer all your questions.</p>
	<a href="{{ CONCIERGE_CHAT_URL }}" target="_blank">
	<div class="submit-button">
	<button class="success">Send a message</button>
	</div>
	</a>
	</div>

The deploy workflow used to build with actions/jekyll-build-pages, which sets JEKYLL_ENV=production internally. Commit a0b7dd3d213 ("Set up ruby env and build site manually") replaced that action with a plain bundle exec jekyll build, which defaults to JEKYLL_ENV=development:

App/.github/workflows/deployExpensifyHelp.yml

Lines 68 to 70 in 374dbdc

	- name: Build Jekyll site
	run: bundle exec jekyll build --source ./ --destination ./_site
	working-directory: ./docs

So the causal chain is: manual build runs in the default development environment → the production branch in CONST.html is skipped → https://dev.new.expensify.com:8082/concierge is baked into every deployed help.expensify.com page → clicking "Send a message" hits a hostname that only resolves on developer machines → DNS_PROBE_FINISHED_NXDOMAIN.

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

Set the environment on the build step in deployExpensifyHelp.yml, restoring what actions/jekyll-build-pages did:

- name: Build Jekyll site
  run: bundle exec jekyll build --source ./ --destination ./_site
  working-directory: ./docs
  env:
    JEKYLL_ENV: production

This fixes every consumer of MAIN_SITE_URL at the single convergence point (the Concierge "Send a message" button, plus anything else that includes CONST.html), for both the production deploy and the Cloudflare PR previews.

What alternative solutions did you explore? (Optional)

Flip the default in docs/_includes/CONST.html so MAIN_SITE_URL is https://new.expensify.com unless jekyll.environment == "development". That would also fix it, but local jekyll serve runs in development by default anyway, so the workflow-level fix is more direct and keeps the config's intent unchanged.

[aswin-s]

Proposal

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

On help.expensify.com (the Help site opened from NewDot → Account → Help → Help site), scrolling to the bottom and clicking the "Send a message" button navigates to https://dev.new.expensify.com:8082/concierge, which fails with a DNS_PROBE_FINISHED_NXDOMAIN error page instead of opening the Concierge chat. The button should take the user to https://new.expensify.com/concierge.

What is the root cause of that problem?

The button's href is generated in docs/_layouts/default.html:114 as {{ CONCIERGE_CHAT_URL }}, which is captured in docs/_includes/CONST.html:7 as {{MAIN_SITE_URL}}/concierge. MAIN_SITE_URL is chosen at docs/_includes/CONST.html:1-5 via {% if jekyll.environment == "production" %} — the production branch sets it to https://new.expensify.com, the else branch sets it to https://dev.new.expensify.com:8082. The deployed help site is being built without JEKYLL_ENV=production, so jekyll.environment defaults to "development", the else branch fires, and every visitor's "Send a message" button points at the dev host that is not publicly resolvable — hence the NXDOMAIN. There is no docs/_config.yml (glob shows no match) to pin this, so the environment must come from the build workflow, and it isn't.

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

1. docs/_includes/CONST.html:1-5 — invert the guard so the safe default is production: use {% if jekyll.environment == "development" %} → dev URL, {% else %} → https://new.expensify.com. That way any build without an explicit env still produces a working public link.
2. Ensure the docs deploy workflow (the GitHub Actions job that publishes help.expensify.com) exports JEKYLL_ENV=production before running jekyll build, so the intent of the current conditional is preserved for future contributors.
3. Audit other consumers of MAIN_SITE_URL / CONCIERGE_CHAT_URL in docs/ for the same defaulting risk (grep in docs/_layouts and docs/_includes) and confirm each is safe under the flipped default.
4. After the fix, verify the rendered <a href> on help.expensify.com (bottom "Send a message" CTA) resolves to https://new.expensify.com/concierge.

What alternative solutions did you explore? (Optional)

Hard-code MAIN_SITE_URL to https://new.expensify.com and drop the environment branch entirely, since the dev URL in a public build is never desired; kept the conditional to preserve local-preview behavior.

[samranahm]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[KJ21-ENG]

Proposal

What is the root cause of that problem?

The Help page in NewDot correctly opens the Help site with CONST.NEWHELP_URL, which is https://help.expensify.com.

App/src/pages/settings/HelpPage/HelpPage.tsx

Lines 109 to 119 in 374dbdc

	const helpSiteItem = {
	key: 'initialSettingsPage.helpPage.helpSite',
	title: translate('initialSettingsPage.helpPage.helpSite'),
	description: translate('initialSettingsPage.helpPage.helpSiteDescription'),
	icon: illustrations.Chalkboard,
	iconType: CONST.ICON_TYPE_AVATAR,
	iconRight: icons.NewWindow,
	onPress: () => openExternalLink(CONST.NEWHELP_URL),
	shouldShowRightIcon: true,
	wrapperStyle: [styles.sectionMenuItemTopDescription],
	link: CONST.NEWHELP_URL,

App/src/CONST/index.ts

Lines 1288 to 1291 in 374dbdc

	STAGING_NEW_EXPENSIFY_URL: 'https://staging.new.expensify.com',
	PR_TESTING_NEW_EXPENSIFY_URL: `https://${CI.PULL_REQUEST_NUMBER}.pr-testing.expensify.com`,
	NEWHELP_URL: 'https://help.expensify.com',
	CHASE_ACCOUNT_NUMBER_HELP_URL: 'https://help.expensify.com/articles/new-expensify/wallet-and-payments/Connect-a-Personal-Bank-Account',

The broken URL is generated by the HelpDot layout itself. The bottom "Send a message" CTA uses CONCIERGE_CHAT_URL, and that value comes from docs/_includes/CONST.html. For any Jekyll build where jekyll.environment is not exactly production, this include sets MAIN_SITE_URL to https://dev.new.expensify.com:8082, so the deployed Help site can render the CTA as https://dev.new.expensify.com:8082/concierge, which is not a public host.

App/docs/_layouts/default.html

Lines 109 to 118 in 374dbdc

	<!-- Concierge button at the bottom of the page -->
	{% include CONST.html %}
	<div class="get-help">
	<h2 class="title with-margin">Didn't find what you were looking for?</h2>
	<p class="description">Concierge is here to answer all your questions.</p>
	<a href="{{ CONCIERGE_CHAT_URL }}" target="_blank">
	<div class="submit-button">
	<button class="success">Send a message</button>
	</div>
	</a>

App/docs/_includes/CONST.html

Lines 1 to 7 in 374dbdc

	{% if jekyll.environment == "production" %}
	{% assign MAIN_SITE_URL = "https://new.expensify.com" %}
	{% else %}
	{% assign MAIN_SITE_URL = "https://dev.new.expensify.com:8082" %}
	{% endif %}
	{% capture CONCIERGE_CHAT_URL %}{{MAIN_SITE_URL}}/concierge{% endcapture %}

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

Change the HelpDot constant used for CONCIERGE_CHAT_URL so the public Help site always points the bottom CTA at the public NewDot Concierge route, https://new.expensify.com/concierge. The smallest fix is to stop using the non-production Jekyll fallback for this customer-facing CTA, or invert it so https://new.expensify.com is the default and a dev URL is used only when an explicit local-help-site flag is set.

Call-site impact: CONCIERGE_CHAT_URL is consumed by the single bottom CTA in docs/_layouts/default.html, so this change only affects the "Send a message" button. MAIN_SITE_URL is only defined in docs/_includes/CONST.html for that generated Concierge URL, so there are no other HelpDot links depending on the current dev fallback.

Test coverage:

• Build or serve the HelpDot docs and verify the rendered bottom CTA href is https://new.expensify.com/concierge.
• Add a lightweight docs/template test or snapshot check for docs/_includes/CONST.html / docs/_layouts/default.html so the rendered Send a message CTA never contains dev.new.expensify.com.
• Manually verify Account > Help > Help site > Send a message on web opens the NewDot Concierge route instead of a DNS error page.

What alternative solutions did you explore? (Optional)

An alternative is to change the NewDot Account > Help page to open an in-app Concierge chat instead of opening HelpDot, but that would remove the user's path to Help articles and does not fix the broken HelpDot CTA for users who land on help.expensify.com directly. I also considered changing the App's HTML environment-link rewrite helper, but that helper only runs on chat comment HTML inside NewDot and is not involved in the HelpDot page served from help.expensify.com.

[melvin-bot]

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