@autobusal/providers 1.29.3 → 1.30.0

package/CHANGELOG.md

@@ -1,5 +1,28 @@
 # Changelog
 
+## 1.30.0
+
+### Added
+
+- **`BootstrapError` tells a transient failure from a real one and recovers
+  by itself.** A rate limit or a dropped connection is not a system error,
+  and "something broke on our side" is wrong twice for either: it blames the
+  wrong thing, and it hands the visitor a reload button for a situation where
+  reloading immediately makes it worse. 429/503/504 and a request with no
+  response at all now get their own wording and an automatic retry that backs
+  off 5s, 10s, 20s, 30s.
+
+## 1.29.4
+
+### Added
+
+- **`OrderData.addons`** (`OrderAddonData[]`) - the extra services bought at
+  checkout. There is no `data` field by design: the API withholds it because
+  the Telegram add-on's copy holds a bind token.
+- **`OrderData.fare_display`** - the fare WITHOUT add-ons. Optional, because
+  only the single-order endpoint opts into it; `amount_display` remains fare +
+  add-ons.
+
 ## 1.29.3
 
 ### Fixed

package/Errors/BootstrapError.tsx

@@ -35,11 +35,63 @@ interface Props {
  * *into*. A full reload is the honest recovery, and it is what a visitor
  * would do anyway.
  */
-class BootstrapError extends React.Component<Props, { failed: boolean }> {
-  state = { failed: false };
+/**
+ * Is this a failure that fixes itself?
+ *
+ * Edited: Ferjolt Ozuni - Date: 2026-08-07
+ *
+ * A rate limit and a dropped connection are not system errors, and telling
+ * somebody "something broke on our side" for either is wrong twice over: it
+ * blames the wrong thing, and it hands them a reload button for a situation
+ * where reloading immediately is the one move that makes it worse.
+ *
+ * Read off the axios error rather than the message text, which is not
+ * stable. A 429 carries a status; a network failure carries none at all,
+ * which is what distinguishes it from a server that answered with a fault.
+ */
+const transient = (error: any): 'busy' | 'offline' | null => {
+  const status = error?.response?.status ?? error?.status;
+
+  if (status === 429) {
+    return 'busy';
+  }
+
+  if (status === 503 || status === 504) {
+    return 'busy';
+  }
+
+  // No response at all - DNS, offline, connection refused, CORS preflight
+  // that never landed. Distinct from a server that replied with a 500.
+  if (error?.isAxiosError && !error?.response) {
+    return 'offline';
+  }
+
+  return null;
+};
+
+/**
+ * How long to wait before trying again.
+ *
+ * The rate limiter's window is a minute, so a few seconds is usually enough
+ * and a full minute feels broken. Backs off on each successive failure so a
+ * genuinely overloaded server is not hammered by every open tab at once.
+ */
+const DELAYS = [ 5, 10, 20, 30 ];
+
+interface State {
+  failed: boolean
+  kind: 'busy' | 'offline' | null
+  attempt: number
+  countdown: number
+}
 
-  static getDerivedStateFromError() {
-    return { failed: true };
+class BootstrapError extends React.Component<Props, State> {
+  state: State = { failed: false, kind: null, attempt: 0, countdown: 0 };
+
+  private timer?: ReturnType<typeof setInterval>;
+
+  static getDerivedStateFromError(error: Error) {
+    return { failed: true, kind: transient(error) };
   }
 
   componentDidCatch(error: Error, info: React.ErrorInfo): void {
@@ -47,6 +99,45 @@ class BootstrapError extends React.Component<Props, { failed: boolean }> {
     // knows the app failed to start, and a white page with a `log` entry is
     // easy to miss when somebody finally does open the console.
     console.error('[bootstrap] the application could not start', error, info);
+
+    /*
+     * A transient failure retries itself. The visitor did nothing wrong and
+     * has nothing useful to do, so asking them to press a button is asking
+     * them to do our waiting for us - and the thing they would press it for
+     * is a rate limit that clears on its own.
+     */
+    if (transient(error)) {
+      this.countdownTo(this.state.attempt);
+    }
+  }
+
+  componentWillUnmount(): void {
+    if (this.timer) {
+      clearInterval(this.timer);
+    }
+  }
+
+  private countdownTo(attempt: number): void {
+    const seconds = DELAYS[Math.min(attempt, DELAYS.length - 1)];
+
+    this.setState({ countdown: seconds });
+
+    this.timer = setInterval(() => {
+      this.setState(state => {
+        if (state.countdown > 1) {
+          return { ...state, countdown: state.countdown - 1 };
+        }
+
+        clearInterval(this.timer);
+
+        // A full reload rather than resetting this boundary: whatever
+        // suspended did so during bootstrap, so there is no reliable state
+        // to retry INTO - the same reasoning as the button below.
+        window.location.reload();
+
+        return { ...state, countdown: 0 };
+      });
+    }, 1000);
   }
 
   render() {
@@ -59,6 +150,26 @@ class BootstrapError extends React.Component<Props, { failed: boolean }> {
     const language = getLanguage('en');
     const copy = errors[language as keyof typeof errors] ?? errors.en;
 
+    /*
+     * Edited: Ferjolt Ozuni - Date: 2026-08-07
+     * A transient failure gets its own words and its own countdown. The
+     * generic system error keeps the reload button, because for a real
+     * fault there is nothing to wait for.
+     */
+    const { kind, countdown } = this.state;
+
+    const title = kind === 'busy' ? (copy as any).busy ?? copy.system : copy.system;
+
+    const detail = kind === 'busy'
+      ? ((copy as any).busy_detail ?? copy.system_detail)
+      : kind === 'offline'
+        ? ((copy as any).offline_detail ?? copy.system_detail)
+        : copy.system_detail;
+
+    const message = kind
+      ? String(detail).replace('{n}', String(countdown))
+      : detail;
+
     return (
       <div
         role="alert"
@@ -75,11 +186,11 @@ class BootstrapError extends React.Component<Props, { failed: boolean }> {
       >
         <div style={ { maxWidth: '460px', textAlign: 'center' } }>
           <h1 style={ { fontSize: '20px', lineHeight: 1.4, margin: '0 0 12px' } }>
-            { copy.system }
+            { title }
           </h1>
 
           <p style={ { fontSize: '15px', lineHeight: 1.6, margin: '0 0 24px', opacity: 0.8 } }>
-            { copy.system_detail }
+            { message }
           </p>
 
           <button

package/package.json

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

package/stores/user.ts

@@ -20,7 +20,19 @@ export interface UserStore {
 // login/activate/refresh); it's just never written to disk. A bootstrap
 // fetch (see Setup/useUserBootstrap.ts) re-hydrates the full in-memory
 // object shortly after app load using this same reduced signal.
-type PersistedUser = Pick<UserData, 'id' | 'name' | 'name_display' | 'type' | 'status'>;
+// Edited: Ferjolt Ozuni - Date: 2026-08-07
+// `verified` joins the subset because `status` cannot be READ without it.
+// Status 0 means "activation pending" for a self-registered account and
+// "switched off by staff" for one an admin created - and the two get
+// different screens (see @autobusal/auth's Secure). Persisting the status
+// but not the field that disambiguates it meant the first paint after a
+// reload had to guess, and guessed activation: a deactivated employee was
+// shown "enter the 5-digit code we emailed you" for a code that does not
+// exist.
+//
+// It is a verification timestamp, not personal data - it says nothing about
+// who the person is, which is what the rest of this redaction is for.
+type PersistedUser = Pick<UserData, 'id' | 'name' | 'name_display' | 'type' | 'status' | 'verified'>;
 
 const STORAGE_KEY = 'user';
 
@@ -29,7 +41,8 @@ const redact = (user: UserData): PersistedUser => ({
   name: user.name,
   name_display: user.name_display,
   type: user.type,
-  status: user.status
+  status: user.status,
+  verified: user.verified
 });
 
 const stored = localStorage.getItem(STORAGE_KEY);

package/types/orders.ts

@@ -33,6 +33,12 @@ export interface OrderData {
   passengers: TicketData[]
   tickets: number
   amount_display: string
+  /*
+   * Edited: Ferjolt Ozuni - Date: 2026-08-07
+   * The fare WITHOUT add-ons. Optional: only the single-order endpoint opts
+   * into it (it costs a sum query), so the listing does not carry it.
+   */
+  fare_display?: string
   note_cancel: string
   actions: string[]
   created_at: string
@@ -42,6 +48,29 @@ export interface OrderData {
   reference?: OrderData
   updated_at: string
   account?: any
+
+  /*
+   * Edited: Ferjolt Ozuni - Date: 2026-08-07
+   * The extra services bought at checkout. Optional: only the single-order
+   * endpoint loads them, and the listing does not.
+   *
+   * There is no `data` field by design - the API withholds it because the
+   * Telegram add-on's copy holds a bind token. See Libraries\Orders\View.
+   */
+  addons?: OrderAddonData[]
+}
+
+export interface OrderAddonData {
+  id: number
+  // 'flex' | 'whatsapp' | 'telegram' | 'sms' - open, since the registry is
+  // a table and a brand can be given a key this build has never heard of.
+  key: string
+  price: string
+  // The same value with the brand's currency on it. The currency is a label
+  // setting the client is never sent, so this has to be formatted server
+  // side - see Orders\OrderAddon.
+  price_display: string
+  created_at: string
 }
 
 export interface ContactData {