fix(core): fix locale validation for disabled localization and pvt routes#3358
Conversation
…utes
- Fix import in validateLocaleForHostname to use merged config
('discovery.config') instead of default-only config
('discovery.config.default.js'), consistent with all other utils
- Skip locale validation when localization.enabled is false,
consistent with bindingPaths.ts behavior
- Skip locale validation for /pvt/ routes (B2B portal pages
should not be subject to storefront locale validation)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughTwo localization validation utilities add early-return short-circuits to skip hostname/locale binding validation in specific scenarios: when localization is disabled in store configuration, and when requests target private/authenticated routes (paths prefixed with ChangesLocalization Validation Short-Circuits
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
…ocalesSettings LocalesSettings type does not include enabled field — access it via storeConfig.localization?.enabled as done in bindingPaths.ts Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@faststore/api
@faststore/cli
@faststore/components
@faststore/core
@faststore/diagnostics
@faststore/lighthouse
@faststore/sdk
@faststore/ui
commit: |
hellofanny
left a comment
There was a problem hiding this comment.
Nice catch! Thanks! 🚀
…utes (#3358) ## Problem `validateLocaleForHostname` has three bugs that cause 404 on all SSR pages when upgrading to FastStore v4: ### 1. Wrong config import The function imports from `discovery.config.default.js` (FastStore default config only) instead of `discovery.config` (merged default + store config). All other utils in the same codebase use `discovery.config`. This means any locale bindings defined in the store's `discovery.config.js` are completely ignored during validation. ### 2. `localization.enabled` flag not respected When `localization.enabled: false`, the function still runs full hostname/binding validation and returns `notFound: true` for any non-localhost host. All other functions in `bindingPaths.ts` correctly check `!storeConfig.localization?.enabled` and return early — `validateLocaleForHostname` was the only one missing this check. ### 3. `/pvt/` routes incorrectly validated `withLocaleValidationSSR` is applied to all SSR pages including B2B portal pages under `/pvt/`. These are private authenticated routes that have no relationship to storefront locale routing and should never be blocked by locale validation. ## Fix 1. **Import fix**: `discovery.config.default.js` → `discovery.config` 2. **enabled check**: Skip validation when `localization.enabled` is `false`, consistent with `bindingPaths.ts` 3. **pvt bypass**: Skip locale validation for routes starting with `/pvt/` ## Impact Stores upgrading to v4 with `localization.enabled: false` (the default) were getting 404 on all SSR pages (`/pvt/account`, `/pvt/organization-account/...`, etc.) in any non-localhost environment. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Locale validation now correctly short-circuits when localization is disabled, preventing unnecessary validation and avoiding false negatives. * Locale validation is skipped for private/authenticated routes, ensuring those requests proceed without hostname-based locale checks and improving request handling for protected paths. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/vtex/faststore/pull/3358?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Problem
validateLocaleForHostnamehas three bugs that cause 404 on all SSR pages when upgrading to FastStore v4:1. Wrong config import
The function imports from
discovery.config.default.js(FastStore default config only) instead ofdiscovery.config(merged default + store config). All other utils in the same codebase usediscovery.config.This means any locale bindings defined in the store's
discovery.config.jsare completely ignored during validation.2.
localization.enabledflag not respectedWhen
localization.enabled: false, the function still runs full hostname/binding validation and returnsnotFound: truefor any non-localhost host.All other functions in
bindingPaths.tscorrectly check!storeConfig.localization?.enabledand return early —validateLocaleForHostnamewas the only one missing this check.3.
/pvt/routes incorrectly validatedwithLocaleValidationSSRis applied to all SSR pages including B2B portal pages under/pvt/. These are private authenticated routes that have no relationship to storefront locale routing and should never be blocked by locale validation.Fix
discovery.config.default.js→discovery.configlocalization.enabledisfalse, consistent withbindingPaths.ts/pvt/Impact
Stores upgrading to v4 with
localization.enabled: false(the default) were getting 404 on all SSR pages (/pvt/account,/pvt/organization-account/..., etc.) in any non-localhost environment.🤖 Generated with Claude Code
Summary by CodeRabbit