@cloudparse/up-miniapps-sdk 0.9.0 → 0.10.0

package/dist/index.cjs

@@ -3665,7 +3665,7 @@ var RoutingService = {
 };
 
 // package.json
-var version = "0.9.0";
+var version = "0.10.0";
 
 // src/sdk.ts
 function deepFreeze(obj) {
@@ -3859,9 +3859,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);
     }
   });
   /**
@@ -5690,10 +5703,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() {