Feed

Hi @Durga Prasad

Good news this matches a recently reported, unresolved bug rather than something exotic to your app. 

is enabled on the Connected App, Salesforce issues a new refresh_token on every refresh and invalidates the old one but the Android Mobile SDK's  

, the SDK force-logs-out the user.  

That produces exactly your symptoms: intermittent (only after the second refresh cycle), "could not refresh token," and an unexpected full logout that drops the local session. 

I checked the 13.2.1 release notes (your version) they only cover Login-for-Admin/passkey MFA changes, with no mention of this fix, so 13.2.1 almost certainly still has the bug. Since React Native's Mobile SDK wrapper sits on top of the native Android/iOS libraries, this bug lives underneath the RN layer, not in your JS code. 

1. Confirm Refresh Token Rotation is on 
   Setup → App Manager → your Connected App → OAuth Policies. If 'Refresh Token Rotation' or 'Rotate Refresh Token After Each Use' is enabled, this is almost certainly your cause.

2. Immediate mitigation: disable rotation 
   If there's no hard compliance requirement forcing rotation, disable it on the Connected App as a stopgap. This removes the trigger condition entirely with zero code changes, while a permanent SDK fix is pending.

3. If rotation must stay on: patch locally 
   Fork/patch SalesforceMobileSDK-Android's ClientManager.java: after updateAccount() succeeds in refreshStaleToken(), explicitly persist the new refresh token via AccountManager.setPassword() (encrypted) instead of relying on buildAuthBundle(), which omits it. The issue thread has the exact suggested diff.

4. Track the upstream fix 
   Watch forcedotcom/SalesforceMobileSDK-Android issue #2879 for the release that ships the official fix, then remove your local patch and bump the SDK version.

5. Check iOS separately 
   I didn't find a matching iOS issue in the tracker worth explicitly testing whether iOS exhibits the same drop, since the fix (and possibly the bug) may be Android-specific.

 Reference: GitHub Issue #2879 — SalesforceMobileSDK-Android 

One thing worth flagging as a senior consultant would: don't silently disable Refresh Token Rotation if it was turned on for a security/compliance reason (rotation exists specifically to limit replay risk if a refresh token leaks) confirm with whoever owns that Connected App's security posture before flipping it off, even as a "temporary" fix. 

I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.

Hi @Shanika Nishani

Why this happens 

The routes.json dynamic-route syntax you may have seen in Salesforce docs applies to pro-code LWR apps built with the standalone LWR framework/CLI (outside Experience Cloud entirely) not to LWR sites built in Experience Builder. In Experience Builder, you don't get direct access to routes.json; the platform generates routing config from what you set in the Pages panel, and that UI only accepts static, hyphenated paths. 

The one built-in exception 

Object/Record Detail pages do support a dynamic segment automatically e.g. /s/product/{recordId} or /s/product/{urlName} but only because that's a special out-of-the-box "Object Page" type tied to a Supported Object via the UI API. You don't configure that path pattern yourself; it comes for free with that page type. It won't generalize to an arbitrary custom page. 

Practical workarounds 

1. Query parameters (supported, no workaround needed) /test?QP=testRecord, read via CurrentPageReference in your LWC. This is the intended mechanism for passing dynamic values to a custom LWR page.
2. Edge/CDN URL rewrite if your custom domain sits behind a CDN or reverse proxy you control (Cloudflare, Akamai, CloudFront, etc.), add a rewrite rule that maps /test/testRecord → /test?QP=testRecord before the request hits Salesforce. The browser URL stays pretty; Salesforce still only ever sees the query-param version. This is the most common way teams get "clean URLs" on Experience Cloud today.
3. Object Page pattern, generalized if what you actually want is "detail page keyed by a record's URL-friendly name," consider modeling it as a real Object Page against a Supported Object rather than a generic custom page then you inherit the dynamic-path behavior natively instead of fighting the custom-page path field.
4. True pro-code LWR if dynamic path routing is a hard requirement, that's a signal this isn't a fit for an Experience Builder-managed site at all; a decoupled/headless approach (LWR OSS app, or a separate front-end calling Salesforce APIs) gives you full routes.json control, at the cost of losing Experience Builder's drag-and-drop admin experience.

Given the trade-offs, most teams end up on option 2 (CDN rewrite) since it needs zero Salesforce-side changes and keeps admins working in Experience Builder normally. If you want to go that route, worth confirming first whether you're using Salesforce's own domain/CDN or a custom DNS setup in front of it that determines whether you even have a layer available to add the rewrite rule. 

I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.