@autobusal/providers 1.37.5 → 1.37.7

package/CHANGELOG.md

@@ -1,5 +1,22 @@
 # Changelog
 
+## 1.37.7
+
+### Added
+
+- **`OrderData.owner_category`** - `'agency' | 'operator' | 'individual'`, who actually owns an order, collapsed to what a viewer outside the account needs to know: who to contact if it needs to change. See `Libraries\Orders\View::ownerCategory()` (obtapi).
+
+### Changed
+
+- **`OrderData.comission_affiliate_display` is now optional.** obtapi's `View::get()` hides every `comission_*_display` field on a restricted (public lookup) response - see that method's own `$restricted` parameter for why.
+
+## 1.37.6
+
+### Fixed
+
+- **The DOM-corruption self-heal watchdog now actually recovers every navigation it's supposed to.** It had two gaps that left users stuck exactly like the bug it exists to catch: its 10-second reload cooldown was tracked globally, so a SECOND corrupted navigation to a different URL within 10s of a first one was silently swallowed - no reload, no recovery, stuck. Scoped the cooldown per-URL instead: a fresh URL always gets a fresh recovery attempt; only a repeat failure on the SAME URL is throttled (the loop-protection this cooldown exists for in the first place). It also only listened for synchronous `error` events - a promise-rejection-based failure (plausible from the lazy()/dynamic-import machinery a route transition drives) was invisible to it and got no recovery at all. Added an `unhandledrejection` listener alongside the existing one, both routed through the same recovery check.
+- **`apiClient`'s 401 handler no longer redirects multiple times for one dead session.** A page boot fires several requests in parallel (settings, menu, account refresh, whatever the current page needs); on a stale/invalid session every one of them 401s within the same tick, and each independently ran its own async `/session` confirmation and its own `window.location.href` redirect - the existing pathname guard only protects against a request that 401s AFTER a redirect has already navigated away, not against several 401s racing each other before any of them has. Reproduced live: a stale session landed on `/account/logout`, and before that page's own logout mutation finished, a second queued redirect (from another request's 401, still in flight when the first one fired) reloaded the page again - repeatedly, stacking a fresh "logged out" toast for every concurrent 401 the boot had fired. Now guarded with a synchronous flag set before the async confirmation, so only the first 401 of a burst does the work; every other one concurrent with it short-circuits immediately.
+
 ## 1.37.5
 
 ### Fixed

package/Providers.tsx

@@ -31,30 +31,69 @@ interface Props {
 // LoginAs.tsx carry a second, more targeted watchdog (a plain timer, not
 // error-triggered) for the two pages users actually get stuck on during
 // impersonation - this one is the general backstop for everywhere else.
+//
+// Edited: Ferjolt Ozuni - Date: 2026-08-11
+// Two gaps closed after this was reported as still reproducing in the wild
+// ("have to click twice", and separately "sometimes I have to refresh
+// myself"):
+//
+// 1. The cooldown used to be a single global timestamp, so ANY two
+// corruptions within 10s of each other - on two DIFFERENT navigations, e.g.
+// a visitor clicking through Help > a category > an article - had the
+// SECOND one silently swallowed: no reload, no error shown, stuck exactly
+// as reported, with a manual refresh as the only way out. The cooldown's
+// actual job is loop protection - stop the SAME failing reload from firing
+// forever - so it only needs to compare against the last recovery done for
+// THIS SAME url; a corruption on a new url is a fresh problem and should
+// always self-heal immediately.
+//
+// 2. This only ever listened for a synchronous, thrown `error` event. React's
+// commit-phase work (and the lazy()/dynamic import() machinery a route
+// transition drives) also has promise-based failure paths, which surface as
+// `unhandledrejection`, not `error` - a corruption landing through one of
+// those was never seen by this handler at all, so no reload ever fired.
+// Both event types are handled by the same recovery function now, since the
+// only thing distinguishing them is which browser event carries the message.
 const useRecoverFromDomCorruption = (): void => {
   useEffect(() => {
-    const RECOVERY_KEY = 'autobusalDomRecoveryAt';
+    const RECOVERY_AT_KEY = 'autobusalDomRecoveryAt';
+    const RECOVERY_URL_KEY = 'autobusalDomRecoveryUrl';
 
-    const onError = (event: ErrorEvent): void => {
-      const message = event.message || '';
+    const isDomCorruption = (message: string): boolean => (
+      message.includes('removeChild') || message.includes('insertBefore')
+    );
 
-      if (!message.includes('removeChild') && !message.includes('insertBefore')) {
+    const recover = (message: string): void => {
+      if (!isDomCorruption(message)) {
         return;
       }
 
-      const last = Number(sessionStorage.getItem(RECOVERY_KEY) || 0);
+      const here = window.location.href;
+      const lastUrl = sessionStorage.getItem(RECOVERY_URL_KEY);
+      const lastAt = Number(sessionStorage.getItem(RECOVERY_AT_KEY) || 0);
 
-      if (Date.now() - last < 10000) {
+      if (lastUrl === here && Date.now() - lastAt < 10000) {
         return;
       }
 
-      sessionStorage.setItem(RECOVERY_KEY, String(Date.now()));
+      sessionStorage.setItem(RECOVERY_AT_KEY, String(Date.now()));
+      sessionStorage.setItem(RECOVERY_URL_KEY, here);
       window.location.reload();
     };
 
+    const onError = (event: ErrorEvent): void => recover(event.message || '');
+
+    const onRejection = (event: PromiseRejectionEvent): void => (
+      recover(event.reason?.message || String(event.reason ?? ''))
+    );
+
     window.addEventListener('error', onError);
+    window.addEventListener('unhandledrejection', onRejection);
 
-    return () => window.removeEventListener('error', onError);
+    return () => {
+      window.removeEventListener('error', onError);
+      window.removeEventListener('unhandledrejection', onRejection);
+    };
   }, []);
 };
 

package/Queries/apiClient.ts

@@ -56,12 +56,39 @@ apiClient.interceptors.request.use(config => {
   return config;
 });
 
+// Edited: Ferjolt Ozuni - Date: 2026-08-11
+// A page boot fires several requests in parallel (settings, menu, account
+// refresh, whatever the current page needs) - on a stale/invalid session
+// every one of them 401s within the same tick. Without this, EACH ran its
+// own async `/session` confirmation and, once that resolved, its own
+// `window.location.href` assignment - independently, since the pathname
+// guard below only protects against a request that 401s AFTER a redirect
+// has already navigated the page away, not against several 401s racing each
+// other BEFORE any of them has. Reproduced live: a stale session landed on
+// /account/logout, Logout.tsx ran its own fresh logout call and toast, and
+// before that finished a SECOND queued redirect (from another request's
+// 401, still in flight when the first one fired) reloaded the page again -
+// repeatedly, each reload restarting Logout.tsx's mutation and stacking
+// another "logged out" toast, for as many concurrent 401s as the boot had
+// fired. Sets synchronously, before the async confirmation - JS runs the
+// check-and-set with nothing else able to interleave before the next
+// `await` - so only the first 401 of a burst does the confirmation work;
+// every other one concurrent with it short-circuits immediately instead of
+// each independently re-deciding the same thing.
+let redirectingToLogout = false;
+
 apiClient.interceptors.response.use(response => (
   response
 ), async (error) => {
   if (error.response) {
     // if we have a 401, the session is gone, so we go to the logout page.
     if (error.response.status === 401 && window.location.pathname !== '/account/logout') {
+      if (redirectingToLogout) {
+        return Promise.reject(error);
+      }
+
+      redirectingToLogout = true;
+
       // bff mode: auth is a server-side httpOnly cookie the BFF manages, so a
       // single request's 401 does NOT reliably mean "logged out" the way a
       // bearer 401 does - a query that momentarily races the login/cookie
@@ -76,6 +103,8 @@ apiClient.interceptors.response.use(response => (
           const { data } = await apiClient.get('/session');
 
           if (data?.authenticated) {
+            redirectingToLogout = false;
+
             return Promise.reject(error);
           }
         } catch {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@autobusal/providers",
-  "version": "1.37.5",
+  "version": "1.37.7",
   "author": "Ferjolt Ozuni",
   "type": "module",
   "main": "index.ts"

package/types/orders.ts

@@ -42,7 +42,17 @@ export interface OrderData {
   note_cancel: string
   actions: string[]
   created_at: string
-  comission_affiliate_display: string
+  /*
+   * Edited: Ferjolt Ozuni - Date: 2026-08-11
+   * Who owns this order, collapsed to what a viewer outside the account
+   * needs to know: who to contact if it needs to change. See
+   * Libraries\Orders\View::ownerCategory() (obtapi) for the mapping.
+   */
+  owner_category: 'agency' | 'operator' | 'individual'
+  // Edited: Ferjolt Ozuni - Date: 2026-08-11
+  // Optional now: hidden on a restricted response (the public order lookup
+  // and any other non-self-service view) - see View::get()'s $restricted.
+  comission_affiliate_display?: string
   name_display?: string
   occupied: string
   reference?: OrderData