@sendoracloud/sdk-react-native 1.8.0 → 1.8.2

package/dist/index.cjs

@@ -222,7 +222,7 @@ async function request(opts, method, path, body, extraHeaders, reqOpts) {
 // package.json
 var package_default = {
   name: "@sendoracloud/sdk-react-native",
-  version: "1.8.0",
+  version: "1.8.2",
   description: "Sendora Cloud React Native + Expo SDK \u2014 analytics, identity, push-token registration, auth, deep links (Branch / Firebase Dynamic Links parity). Auth + analytics + deep links work in Expo Go; push token registration requires a Dev Client (EAS Build or `npx expo prebuild`).",
   type: "module",
   main: "./dist/index.cjs",
@@ -465,38 +465,44 @@ var Auth = class {
     }
   }
   /**
-   * Returns an access token or null. Cold-launch hardening (Wave 62):
+   * Returns a VALID (non-expired) access token, or null.
    *
-   *  1. Non-expired cached → return it. (Fast path.)
-   *  2. Expired AND refresh inflight → return stale cached anyway.
-   *     Backend grace window (60s — see auth-service refresh-rotation
-   *     middleware) accepts slightly-stale access tokens, so the
-   *     caller's downstream RPC will succeed against grace while
-   *     the in-flight refresh resolves out of band. Distinct from
-   *     pre-Wave-62 behaviour where 5 concurrent callers all shared
-   *     the same in-flight promise — when that promise hung (iOS
-   *     NSURLSession cold-launch contention) every caller hung too.
-   *  3. Expired + no inflight + refresh available + not in cooldown →
-   *     fire refresh, await it.
-   *  4. Expired + in cooldown → return stale cached. Caller's RPC
-   *     either succeeds against grace or fails fast on 401, which is
-   *     a better UX than blocking the whole bridge waiting on a
-   *     network that we already know is stalled.
+   * Hard contract (matches sdk-ios / sdk-android, and the industry
+   * token-client pattern — Supabase `_callRefreshToken`, Auth0
+   * `getTokenSilently`, Firebase `getIdToken`): this method NEVER
+   * returns a token past its `exp`. Callers attach the result as a
+   * Bearer to arbitrary resource servers — including third-party
+   * backends (PostgREST/Supabase) that have NO knowledge of Sendora's
+   * own refresh grace window — so a token must be either fresh or
+   * absent. A token expired by hours is useless and yields a 401.
    *
-   * Returns null only when there's NO usable token at all (no cached
-   * + no refresh available).
+   * Resolution order:
+   *  1. Cached token with comfortable life left (>= REFRESH_SAFETY_MS
+   *     skew before exp) → return it. Fast path, no I/O.
+   *  2. No cached token AND no refresh token in storage → genuinely
+   *     signed out → null.
+   *  3. Expired/near-expiry but a refresh chain exists:
+   *     a. A refresh is already inflight → AWAIT it and return the
+   *        fresh token. Concurrent callers coalesce onto the single
+   *        in-flight `/token/refresh` (single-flight) — nobody is
+   *        handed a stale token. The inflight fetch is
+   *        AbortController-bounded (http.ts caps `/auth-service/*` at
+   *        10s), so awaiting can NEVER hang the JS bridge. That
+   *        bounded-fetch guarantee — NOT the old stale-token return —
+   *        is what actually fixed the Wave-62 cold-launch hang.
+   *     b. A recent refresh failed and we're in backoff cooldown →
+   *        null. Honest "no usable token right now" rather than a
+   *        provably-expired one; the AppState foreground hook clears
+   *        the cooldown for an immediate retry on resume.
+   *     c. Otherwise → fire the refresh and await it.
    */
   async getAccessToken() {
-    if (!this.accessToken) return null;
-    if (this.accessExpiresAt && Date.now() < this.accessExpiresAt - REFRESH_SAFETY_MS) {
-      return this.accessToken;
-    }
-    if (this.refreshInflight) {
-      return this.accessToken;
-    }
-    if (Date.now() < this.refreshCooldownUntil) {
+    if (this.accessToken && this.accessExpiresAt && Date.now() < this.accessExpiresAt - REFRESH_SAFETY_MS) {
       return this.accessToken;
     }
+    if (!this.hooks.storage.get(REFRESH_KEY)) return null;
+    if (this.refreshInflight) return this.refreshInflight;
+    if (Date.now() < this.refreshCooldownUntil) return null;
     return this.refreshAccessToken();
   }
   /** Sync read — returns whatever's cached even if expired. Prefer the async variant. */
@@ -865,12 +871,22 @@ var Auth = class {
    *     `scheduledPurgeAt`. The user can CANCEL by signing back in before then.
    * Either outcome wipes local identity (the server has already revoked the
    * session). Requires a signed-in user. Throws on a non-2xx response.
+   *
+   * Resolves a FRESH access token via `getAccessToken()` first (refreshing if
+   * the cached one expired) — unlike the other Bearer calls this is a one-shot
+   * destructive action, so a 401 from a stale token would silently strand the
+   * user with an undeleted account. A stale `this.accessToken` was the cause of
+   * the 401s seen in prod when a user tapped "delete" after the app sat idle.
    */
   async deleteAccount() {
+    const token = await this.getAccessToken();
+    if (!token) {
+      throw new AuthError("NOT_SIGNED_IN", "Sign in before deleting your account");
+    }
     const res = await del(
       { apiUrl: this.hooks.apiUrl, publicKey: this.hooks.publicKey, debug: this.hooks.debug },
       "/api/v1/auth-service/me",
-      this.bearerHeaders()
+      { Authorization: `Bearer ${token}` }
     );
     if (!res || !res.ok) {
       throw new Error(`deleteAccount failed${res ? ` (HTTP ${res.status})` : " (network error)"}`);

package/dist/index.d.cts

@@ -210,26 +210,36 @@ declare class Auth {
     /** Internal — fan out to subscribers + cache the latest. */
     private fireDeviceTakeover;
     /**
-     * Returns an access token or null. Cold-launch hardening (Wave 62):
+     * Returns a VALID (non-expired) access token, or null.
      *
-     *  1. Non-expired cached → return it. (Fast path.)
-     *  2. Expired AND refresh inflight → return stale cached anyway.
-     *     Backend grace window (60s — see auth-service refresh-rotation
-     *     middleware) accepts slightly-stale access tokens, so the
-     *     caller's downstream RPC will succeed against grace while
-     *     the in-flight refresh resolves out of band. Distinct from
-     *     pre-Wave-62 behaviour where 5 concurrent callers all shared
-     *     the same in-flight promise — when that promise hung (iOS
-     *     NSURLSession cold-launch contention) every caller hung too.
-     *  3. Expired + no inflight + refresh available + not in cooldown →
-     *     fire refresh, await it.
-     *  4. Expired + in cooldown → return stale cached. Caller's RPC
-     *     either succeeds against grace or fails fast on 401, which is
-     *     a better UX than blocking the whole bridge waiting on a
-     *     network that we already know is stalled.
+     * Hard contract (matches sdk-ios / sdk-android, and the industry
+     * token-client pattern — Supabase `_callRefreshToken`, Auth0
+     * `getTokenSilently`, Firebase `getIdToken`): this method NEVER
+     * returns a token past its `exp`. Callers attach the result as a
+     * Bearer to arbitrary resource servers — including third-party
+     * backends (PostgREST/Supabase) that have NO knowledge of Sendora's
+     * own refresh grace window — so a token must be either fresh or
+     * absent. A token expired by hours is useless and yields a 401.
      *
-     * Returns null only when there's NO usable token at all (no cached
-     * + no refresh available).
+     * Resolution order:
+     *  1. Cached token with comfortable life left (>= REFRESH_SAFETY_MS
+     *     skew before exp) → return it. Fast path, no I/O.
+     *  2. No cached token AND no refresh token in storage → genuinely
+     *     signed out → null.
+     *  3. Expired/near-expiry but a refresh chain exists:
+     *     a. A refresh is already inflight → AWAIT it and return the
+     *        fresh token. Concurrent callers coalesce onto the single
+     *        in-flight `/token/refresh` (single-flight) — nobody is
+     *        handed a stale token. The inflight fetch is
+     *        AbortController-bounded (http.ts caps `/auth-service/*` at
+     *        10s), so awaiting can NEVER hang the JS bridge. That
+     *        bounded-fetch guarantee — NOT the old stale-token return —
+     *        is what actually fixed the Wave-62 cold-launch hang.
+     *     b. A recent refresh failed and we're in backoff cooldown →
+     *        null. Honest "no usable token right now" rather than a
+     *        provably-expired one; the AppState foreground hook clears
+     *        the cooldown for an immediate retry on resume.
+     *     c. Otherwise → fire the refresh and await it.
      */
     getAccessToken(): Promise<string | null>;
     /** Sync read — returns whatever's cached even if expired. Prefer the async variant. */
@@ -353,6 +363,12 @@ declare class Auth {
      *     `scheduledPurgeAt`. The user can CANCEL by signing back in before then.
      * Either outcome wipes local identity (the server has already revoked the
      * session). Requires a signed-in user. Throws on a non-2xx response.
+     *
+     * Resolves a FRESH access token via `getAccessToken()` first (refreshing if
+     * the cached one expired) — unlike the other Bearer calls this is a one-shot
+     * destructive action, so a 401 from a stale token would silently strand the
+     * user with an undeleted account. A stale `this.accessToken` was the cause of
+     * the 401s seen in prod when a user tapped "delete" after the app sat idle.
      */
     deleteAccount(): Promise<{
         status: "purged" | "pending";

package/dist/index.d.ts

@@ -210,26 +210,36 @@ declare class Auth {
     /** Internal — fan out to subscribers + cache the latest. */
     private fireDeviceTakeover;
     /**
-     * Returns an access token or null. Cold-launch hardening (Wave 62):
+     * Returns a VALID (non-expired) access token, or null.
      *
-     *  1. Non-expired cached → return it. (Fast path.)
-     *  2. Expired AND refresh inflight → return stale cached anyway.
-     *     Backend grace window (60s — see auth-service refresh-rotation
-     *     middleware) accepts slightly-stale access tokens, so the
-     *     caller's downstream RPC will succeed against grace while
-     *     the in-flight refresh resolves out of band. Distinct from
-     *     pre-Wave-62 behaviour where 5 concurrent callers all shared
-     *     the same in-flight promise — when that promise hung (iOS
-     *     NSURLSession cold-launch contention) every caller hung too.
-     *  3. Expired + no inflight + refresh available + not in cooldown →
-     *     fire refresh, await it.
-     *  4. Expired + in cooldown → return stale cached. Caller's RPC
-     *     either succeeds against grace or fails fast on 401, which is
-     *     a better UX than blocking the whole bridge waiting on a
-     *     network that we already know is stalled.
+     * Hard contract (matches sdk-ios / sdk-android, and the industry
+     * token-client pattern — Supabase `_callRefreshToken`, Auth0
+     * `getTokenSilently`, Firebase `getIdToken`): this method NEVER
+     * returns a token past its `exp`. Callers attach the result as a
+     * Bearer to arbitrary resource servers — including third-party
+     * backends (PostgREST/Supabase) that have NO knowledge of Sendora's
+     * own refresh grace window — so a token must be either fresh or
+     * absent. A token expired by hours is useless and yields a 401.
      *
-     * Returns null only when there's NO usable token at all (no cached
-     * + no refresh available).
+     * Resolution order:
+     *  1. Cached token with comfortable life left (>= REFRESH_SAFETY_MS
+     *     skew before exp) → return it. Fast path, no I/O.
+     *  2. No cached token AND no refresh token in storage → genuinely
+     *     signed out → null.
+     *  3. Expired/near-expiry but a refresh chain exists:
+     *     a. A refresh is already inflight → AWAIT it and return the
+     *        fresh token. Concurrent callers coalesce onto the single
+     *        in-flight `/token/refresh` (single-flight) — nobody is
+     *        handed a stale token. The inflight fetch is
+     *        AbortController-bounded (http.ts caps `/auth-service/*` at
+     *        10s), so awaiting can NEVER hang the JS bridge. That
+     *        bounded-fetch guarantee — NOT the old stale-token return —
+     *        is what actually fixed the Wave-62 cold-launch hang.
+     *     b. A recent refresh failed and we're in backoff cooldown →
+     *        null. Honest "no usable token right now" rather than a
+     *        provably-expired one; the AppState foreground hook clears
+     *        the cooldown for an immediate retry on resume.
+     *     c. Otherwise → fire the refresh and await it.
      */
     getAccessToken(): Promise<string | null>;
     /** Sync read — returns whatever's cached even if expired. Prefer the async variant. */
@@ -353,6 +363,12 @@ declare class Auth {
      *     `scheduledPurgeAt`. The user can CANCEL by signing back in before then.
      * Either outcome wipes local identity (the server has already revoked the
      * session). Requires a signed-in user. Throws on a non-2xx response.
+     *
+     * Resolves a FRESH access token via `getAccessToken()` first (refreshing if
+     * the cached one expired) — unlike the other Bearer calls this is a one-shot
+     * destructive action, so a 401 from a stale token would silently strand the
+     * user with an undeleted account. A stale `this.accessToken` was the cause of
+     * the 401s seen in prod when a user tapped "delete" after the app sat idle.
      */
     deleteAccount(): Promise<{
         status: "purged" | "pending";

package/dist/index.js

@@ -179,7 +179,7 @@ async function request(opts, method, path, body, extraHeaders, reqOpts) {
 // package.json
 var package_default = {
   name: "@sendoracloud/sdk-react-native",
-  version: "1.8.0",
+  version: "1.8.2",
   description: "Sendora Cloud React Native + Expo SDK \u2014 analytics, identity, push-token registration, auth, deep links (Branch / Firebase Dynamic Links parity). Auth + analytics + deep links work in Expo Go; push token registration requires a Dev Client (EAS Build or `npx expo prebuild`).",
   type: "module",
   main: "./dist/index.cjs",
@@ -422,38 +422,44 @@ var Auth = class {
     }
   }
   /**
-   * Returns an access token or null. Cold-launch hardening (Wave 62):
+   * Returns a VALID (non-expired) access token, or null.
    *
-   *  1. Non-expired cached → return it. (Fast path.)
-   *  2. Expired AND refresh inflight → return stale cached anyway.
-   *     Backend grace window (60s — see auth-service refresh-rotation
-   *     middleware) accepts slightly-stale access tokens, so the
-   *     caller's downstream RPC will succeed against grace while
-   *     the in-flight refresh resolves out of band. Distinct from
-   *     pre-Wave-62 behaviour where 5 concurrent callers all shared
-   *     the same in-flight promise — when that promise hung (iOS
-   *     NSURLSession cold-launch contention) every caller hung too.
-   *  3. Expired + no inflight + refresh available + not in cooldown →
-   *     fire refresh, await it.
-   *  4. Expired + in cooldown → return stale cached. Caller's RPC
-   *     either succeeds against grace or fails fast on 401, which is
-   *     a better UX than blocking the whole bridge waiting on a
-   *     network that we already know is stalled.
+   * Hard contract (matches sdk-ios / sdk-android, and the industry
+   * token-client pattern — Supabase `_callRefreshToken`, Auth0
+   * `getTokenSilently`, Firebase `getIdToken`): this method NEVER
+   * returns a token past its `exp`. Callers attach the result as a
+   * Bearer to arbitrary resource servers — including third-party
+   * backends (PostgREST/Supabase) that have NO knowledge of Sendora's
+   * own refresh grace window — so a token must be either fresh or
+   * absent. A token expired by hours is useless and yields a 401.
    *
-   * Returns null only when there's NO usable token at all (no cached
-   * + no refresh available).
+   * Resolution order:
+   *  1. Cached token with comfortable life left (>= REFRESH_SAFETY_MS
+   *     skew before exp) → return it. Fast path, no I/O.
+   *  2. No cached token AND no refresh token in storage → genuinely
+   *     signed out → null.
+   *  3. Expired/near-expiry but a refresh chain exists:
+   *     a. A refresh is already inflight → AWAIT it and return the
+   *        fresh token. Concurrent callers coalesce onto the single
+   *        in-flight `/token/refresh` (single-flight) — nobody is
+   *        handed a stale token. The inflight fetch is
+   *        AbortController-bounded (http.ts caps `/auth-service/*` at
+   *        10s), so awaiting can NEVER hang the JS bridge. That
+   *        bounded-fetch guarantee — NOT the old stale-token return —
+   *        is what actually fixed the Wave-62 cold-launch hang.
+   *     b. A recent refresh failed and we're in backoff cooldown →
+   *        null. Honest "no usable token right now" rather than a
+   *        provably-expired one; the AppState foreground hook clears
+   *        the cooldown for an immediate retry on resume.
+   *     c. Otherwise → fire the refresh and await it.
    */
   async getAccessToken() {
-    if (!this.accessToken) return null;
-    if (this.accessExpiresAt && Date.now() < this.accessExpiresAt - REFRESH_SAFETY_MS) {
-      return this.accessToken;
-    }
-    if (this.refreshInflight) {
-      return this.accessToken;
-    }
-    if (Date.now() < this.refreshCooldownUntil) {
+    if (this.accessToken && this.accessExpiresAt && Date.now() < this.accessExpiresAt - REFRESH_SAFETY_MS) {
       return this.accessToken;
     }
+    if (!this.hooks.storage.get(REFRESH_KEY)) return null;
+    if (this.refreshInflight) return this.refreshInflight;
+    if (Date.now() < this.refreshCooldownUntil) return null;
     return this.refreshAccessToken();
   }
   /** Sync read — returns whatever's cached even if expired. Prefer the async variant. */
@@ -822,12 +828,22 @@ var Auth = class {
    *     `scheduledPurgeAt`. The user can CANCEL by signing back in before then.
    * Either outcome wipes local identity (the server has already revoked the
    * session). Requires a signed-in user. Throws on a non-2xx response.
+   *
+   * Resolves a FRESH access token via `getAccessToken()` first (refreshing if
+   * the cached one expired) — unlike the other Bearer calls this is a one-shot
+   * destructive action, so a 401 from a stale token would silently strand the
+   * user with an undeleted account. A stale `this.accessToken` was the cause of
+   * the 401s seen in prod when a user tapped "delete" after the app sat idle.
    */
   async deleteAccount() {
+    const token = await this.getAccessToken();
+    if (!token) {
+      throw new AuthError("NOT_SIGNED_IN", "Sign in before deleting your account");
+    }
     const res = await del(
       { apiUrl: this.hooks.apiUrl, publicKey: this.hooks.publicKey, debug: this.hooks.debug },
       "/api/v1/auth-service/me",
-      this.bearerHeaders()
+      { Authorization: `Bearer ${token}` }
     );
     if (!res || !res.ok) {
       throw new Error(`deleteAccount failed${res ? ` (HTTP ${res.status})` : " (network error)"}`);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sendoracloud/sdk-react-native",
-  "version": "1.8.0",
+  "version": "1.8.2",
   "description": "Sendora Cloud React Native + Expo SDK — analytics, identity, push-token registration, auth, deep links (Branch / Firebase Dynamic Links parity). Auth + analytics + deep links work in Expo Go; push token registration requires a Dev Client (EAS Build or `npx expo prebuild`).",
   "type": "module",
   "main": "./dist/index.cjs",