@cloudparse/up-miniapps-sdk 0.9.0 → 0.10.0

package/dist/index.d.cts

@@ -157,6 +157,27 @@ interface INetworkOptions {
     body?: unknown;
     /** Custom HTTP headers. */
     headers?: Record<string, string>;
+    /**
+     * Real production bug, found live: the shell's NETWORK_REQUEST handler
+     * (`up/shell`'s `use-miniapp-bridge.ts`) hard-caps every proxied request
+     * at a fixed 5s timeout (`fetch-with-timeout.ts`'s `DEFAULT_TIMEOUT_MS`)
+     * with no way for a mini-app to ask for more — a genuinely slow-but-legit
+     * backend call (e.g. an LLM chat turn routinely taking 3-7s+) gets
+     * silently aborted mid-flight ("context canceled" server-side) well
+     * before its own, longer server-side timeout would ever fire. Optional
+     * override, in milliseconds — omit for the shell's existing 5s default.
+     * Only meaningful for `sdk.network.request()`/host-proxied calls; has no
+     * effect on any other bridge message type. Governs TWO independent
+     * ceilings that must move together, not just the shell's own fetch: the
+     * shell's `fetchWithTimeout` call (the actual HTTP request) AND this
+     * bridge's own client-side promise wait for the native reply
+     * (`Bridge.send`'s own `timeoutMs`, default 30s — see `sdk.ts`'s
+     * `network.request`, which forwards this same value there too). Setting
+     * this only high enough for the first would still let the second time out
+     * first on anything over ~30s and silently reject with a generic "Bridge
+     * request timeout" instead of ever reaching the real HTTP response.
+     */
+    timeoutMs?: number;
 }
 /**
  * Response from a network proxy request.
@@ -1550,6 +1571,19 @@ declare class MiniAppSDK {
         /**
          * Performs a network request via the host shell.
          * @param options Request method, URL, headers, and body.
+         *
+         * Real bug, caught by reviewer-strict: `options.timeoutMs` only ever
+         * reached the shell's own `fetchWithTimeout` call — this `bridge.send`
+         * has an entirely separate client-side promise timeout (its own
+         * `timeoutMs` param, default 30000ms) waiting for the native reply,
+         * previously left at that default regardless of what `options.timeoutMs`
+         * said. A slow-but-legitimate call given a longer `options.timeoutMs`
+         * (e.g. 50000ms for an LLM-backed endpoint) would still get this
+         * bridge-level promise rejected ("Bridge request timeout") at 30s,
+         * reintroducing the exact same "aborted before it could finish" bug
+         * this field exists to fix, one layer up. Forwarding it here means both
+         * ceilings move together; omitted (`undefined`, every other caller)
+         * falls through to `send`'s own unchanged 30000ms default.
          */
         request: <T = unknown>(options: INetworkOptions) => Promise<INetworkResponse<T>>;
     }>;
@@ -1732,7 +1766,13 @@ interface ApiServiceClient {
     /** Current WebSocket backend URL, same resolution order as `baseUrl` but reading the dedicated ws fields instead. `undefined` if neither the shell nor `defaultWsBackendUrl` ever supplied one. */
     readonly wsUrl: string | undefined;
     get<T = unknown>(path: string): Promise<INetworkResponse<T>>;
-    post<T = unknown>(path: string, body?: unknown): Promise<INetworkResponse<T>>;
+    /**
+     * `timeoutMs` overrides the shell's default NETWORK_REQUEST timeout (5s,
+     * see `INetworkOptions.timeoutMs`'s own doc comment) — pass it for a call
+     * to a backend route that's legitimately slower than a typical REST call
+     * (e.g. an LLM-backed endpoint), never as a blanket "just in case" bump.
+     */
+    post<T = unknown>(path: string, body?: unknown, timeoutMs?: number): Promise<INetworkResponse<T>>;
     patch<T = unknown>(path: string, body?: unknown): Promise<INetworkResponse<T>>;
     delete(path: string): Promise<INetworkResponse<void>>;
     graphqlQuery<T = unknown>(query: string, variables?: Record<string, unknown>): Promise<INetworkResponse<{

package/dist/index.d.ts

@@ -157,6 +157,27 @@ interface INetworkOptions {
     body?: unknown;
     /** Custom HTTP headers. */
     headers?: Record<string, string>;
+    /**
+     * Real production bug, found live: the shell's NETWORK_REQUEST handler
+     * (`up/shell`'s `use-miniapp-bridge.ts`) hard-caps every proxied request
+     * at a fixed 5s timeout (`fetch-with-timeout.ts`'s `DEFAULT_TIMEOUT_MS`)
+     * with no way for a mini-app to ask for more — a genuinely slow-but-legit
+     * backend call (e.g. an LLM chat turn routinely taking 3-7s+) gets
+     * silently aborted mid-flight ("context canceled" server-side) well
+     * before its own, longer server-side timeout would ever fire. Optional
+     * override, in milliseconds — omit for the shell's existing 5s default.
+     * Only meaningful for `sdk.network.request()`/host-proxied calls; has no
+     * effect on any other bridge message type. Governs TWO independent
+     * ceilings that must move together, not just the shell's own fetch: the
+     * shell's `fetchWithTimeout` call (the actual HTTP request) AND this
+     * bridge's own client-side promise wait for the native reply
+     * (`Bridge.send`'s own `timeoutMs`, default 30s — see `sdk.ts`'s
+     * `network.request`, which forwards this same value there too). Setting
+     * this only high enough for the first would still let the second time out
+     * first on anything over ~30s and silently reject with a generic "Bridge
+     * request timeout" instead of ever reaching the real HTTP response.
+     */
+    timeoutMs?: number;
 }
 /**
  * Response from a network proxy request.
@@ -1550,6 +1571,19 @@ declare class MiniAppSDK {
         /**
          * Performs a network request via the host shell.
          * @param options Request method, URL, headers, and body.
+         *
+         * Real bug, caught by reviewer-strict: `options.timeoutMs` only ever
+         * reached the shell's own `fetchWithTimeout` call — this `bridge.send`
+         * has an entirely separate client-side promise timeout (its own
+         * `timeoutMs` param, default 30000ms) waiting for the native reply,
+         * previously left at that default regardless of what `options.timeoutMs`
+         * said. A slow-but-legitimate call given a longer `options.timeoutMs`
+         * (e.g. 50000ms for an LLM-backed endpoint) would still get this
+         * bridge-level promise rejected ("Bridge request timeout") at 30s,
+         * reintroducing the exact same "aborted before it could finish" bug
+         * this field exists to fix, one layer up. Forwarding it here means both
+         * ceilings move together; omitted (`undefined`, every other caller)
+         * falls through to `send`'s own unchanged 30000ms default.
          */
         request: <T = unknown>(options: INetworkOptions) => Promise<INetworkResponse<T>>;
     }>;
@@ -1732,7 +1766,13 @@ interface ApiServiceClient {
     /** Current WebSocket backend URL, same resolution order as `baseUrl` but reading the dedicated ws fields instead. `undefined` if neither the shell nor `defaultWsBackendUrl` ever supplied one. */
     readonly wsUrl: string | undefined;
     get<T = unknown>(path: string): Promise<INetworkResponse<T>>;
-    post<T = unknown>(path: string, body?: unknown): Promise<INetworkResponse<T>>;
+    /**
+     * `timeoutMs` overrides the shell's default NETWORK_REQUEST timeout (5s,
+     * see `INetworkOptions.timeoutMs`'s own doc comment) — pass it for a call
+     * to a backend route that's legitimately slower than a typical REST call
+     * (e.g. an LLM-backed endpoint), never as a blanket "just in case" bump.
+     */
+    post<T = unknown>(path: string, body?: unknown, timeoutMs?: number): Promise<INetworkResponse<T>>;
     patch<T = unknown>(path: string, body?: unknown): Promise<INetworkResponse<T>>;
     delete(path: string): Promise<INetworkResponse<void>>;
     graphqlQuery<T = unknown>(query: string, variables?: Record<string, unknown>): Promise<INetworkResponse<{

package/dist/index.js

@@ -3441,7 +3441,7 @@ var loadImage2 = (src) => new Promise((resolve, reject) => {
 });
 
 // package.json
-var version = "0.9.0";
+var version = "0.10.0";
 
 // src/sdk.ts
 function deepFreeze(obj) {
@@ -3635,9 +3635,22 @@ var MiniAppSDK = class {
     /**
      * Performs a network request via the host shell.
      * @param options Request method, URL, headers, and body.
+     *
+     * Real bug, caught by reviewer-strict: `options.timeoutMs` only ever
+     * reached the shell's own `fetchWithTimeout` call — this `bridge.send`
+     * has an entirely separate client-side promise timeout (its own
+     * `timeoutMs` param, default 30000ms) waiting for the native reply,
+     * previously left at that default regardless of what `options.timeoutMs`
+     * said. A slow-but-legitimate call given a longer `options.timeoutMs`
+     * (e.g. 50000ms for an LLM-backed endpoint) would still get this
+     * bridge-level promise rejected ("Bridge request timeout") at 30s,
+     * reintroducing the exact same "aborted before it could finish" bug
+     * this field exists to fix, one layer up. Forwarding it here means both
+     * ceilings move together; omitted (`undefined`, every other caller)
+     * falls through to `send`'s own unchanged 30000ms default.
      */
     request: async (options) => {
-      return this.bridge.send("NETWORK_REQUEST", options);
+      return this.bridge.send("NETWORK_REQUEST", options, options.timeoutMs);
     }
   });
   /**
@@ -5406,10 +5419,11 @@ function createApiService(options) {
       method: "PATCH",
       url: buildUrl(getBaseUrl(), path)
     }),
-    post: (path, body) => sdk.network.request({
+    post: (path, body, timeoutMs) => sdk.network.request({
       body,
       headers: { "Content-Type": "application/json" },
       method: "POST",
+      timeoutMs,
       url: buildUrl(getBaseUrl(), path)
     }),
     get wsUrl() {