Skip to main content

Hello Community, 

 

We are currently building a React Native mobile application using the Salesforce Mobile SDK v13.2.1 and utilizing the OAuth Authorization Code Flow with PKCE

for user authentication. 

 

Intermittently, our users are facing an issue where they are unexpectedly logged out of the app. From our log extraction, we captured the following exception details: 

 

  • Error Code in salesforce login history: Unknown exception: 1807

 

Has anyone encountered this specific exception: 1807 status code error before? Are there known configurations or code workarounds within the React Native wrappers to handle or retry this gracefully without dropping the entire local SmartStore session?  

 

Any troubleshooting advice or remediation paths would be highly appreciated.  

 

Thanks! 

1 respuesta
  1. 7 sept, 20:29

    Hi @Durga Prasad

     

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

     

    Root cause (high confidence match): There's an open/closed-with-fix-pending GitHub issue on forcedotcom/SalesforceMobileSDK-Android (#2879, filed May 2026, confirmed on SDK 13.2.0) describing exactly this pattern: when Refresh Token Rotation

    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  

     

    ClientManager.AccMgrAuthTokenProvider.refreshStaleToken() never persists the new refresh token back to AccountManager. The next refresh attempt reads the stale (now-revoked) token, gets rejected, and since revokedTokenShouldLogout defaults to true

    , 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. 

     

    Note on "1807" specifically: that's not a standard Salesforce LoginHistory status code (those are string values like Success/Failed, not numeric IDs) it looks like an internal SDK/app-side exception code from your logging. Worth confirming, but I can't verify the exact 1807→cause mapping without seeing your log wrapper. 

     

    What to do: 

     

    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.

0/9000