hermoso 0.1.503 → 0.1.505

package/mcp/client.mjs

@@ -152,7 +152,7 @@ export function signInMessage(status, body, msg, isSignedOut = signedOut()) {
 // unwrap the {data}|{error} envelope; throw a clean Error (with .status) on failure
 async function unwrap(res, { read = false } = {}) {
   let body = null;
-  try { body = await res.json(); } catch {}
+  try { body = await res.json(); } catch (e) { if (read && isDeadline(e)) throw readDeadlineError(); } // a body cut off by the read deadline is not an empty answer
   if (!res.ok) {
     const msg = signInMessage(res.status, body, (body && (body.error || body.message)) || `HTTP ${res.status}`);
     // `_viaApi` MARKS AN ERROR THAT ALREADY REACHED THE SERVER, so route() has already recorded it in the error
@@ -299,14 +299,26 @@ async function throughFrontDoor(send, { read }) {
   return res;
 }
 
-async function fetchRead(url, init) { return throughFrontDoor(() => fetchReadOnce(url, init), { read: true }); }
+// ── A READ HAS A DEADLINE (2026-11-04) ────────────────────────────────────────────────────────────────────────────
+// fetch has none of its own, only undici's 300-second wait for response headers, and that wait ends in the same bare
+// "fetch failed" as a dropped socket, so the blip retry below SENT THE SLOW READ AGAIN: one hosted
+// read_meta_conversation sat open for the whole 10-minute MCP wall and held off every deploy. A read now ends at
+// READ_DEADLINE_MS with a sentence, and a deadline is never retried (resending a read the server is still working on
+// only doubles the wait). No read a tool makes runs this long: the slowest seen in a week of request logs was under
+// 100 seconds, which is also the edge's limit for a stdio client. A read changes nothing, so ending it is safe.
+export const READ_DEADLINE_MS = Number(process.env.HERMOSO_READ_DEADLINE_MS) > 0 ? Number(process.env.HERMOSO_READ_DEADLINE_MS) : 180000;
+const isDeadline = (e) => !!e && (e.name === 'TimeoutError' || e.name === 'AbortError' || /UND_ERR_(HEADERS|BODY)_TIMEOUT/.test(String(e.cause?.code || '')));
+const readDeadlineError = () => Object.assign(new Error(`Hermoso did not finish that read within ${Math.round(READ_DEADLINE_MS / 1000)} seconds, so it was stopped and nothing came back. It was a read, so nothing was changed. Try again, or ask for less (a smaller limit or one account).`), { status: 504, _readDeadline: true });
+async function fetchRead(url, init) { return throughFrontDoor(() => fetchReadOnce(url, { ...init, signal: AbortSignal.timeout(READ_DEADLINE_MS) }), { read: true }); }
 async function fetchReadOnce(url, init) {
   try { return await fetch(url, init); }
   catch (e) {
+    if (isDeadline(e)) throw readDeadlineError();
     if (!isTransport(e)) throw e;
     await new Promise((r) => setTimeout(r, 400));
     try { return await fetch(url, init); }
     catch (e2) {
+      if (isDeadline(e2)) throw readDeadlineError();
       if (!isTransport(e2)) throw e2;
       throw Object.assign(new Error('Could not reach Hermoso just now — the request never got a response, so nothing was read. This is a connection problem, not a rejected request; try again.'), { _transport: true, _viaApi: true });
     }

package/mcp/http.mjs

@@ -162,6 +162,10 @@ export function mountRemoteMcp(app, { verifyBearer, publicBaseUrl, onSessionStar
   const GET_STREAM_MS = Math.max(1000, Number(process.env.MCP_GET_STREAM_MS || 5 * 60e3));
 const MCP_CALL_WALL_MS = Number(process.env.MCP_CALL_WALL_MS) || 10 * 60 * 1000; // a tools/call still open after this is ended, so a ghost cannot pin a deploy or a slot
 const inflightNameOf = (body) => { const msgs = Array.isArray(body) ? body : [body]; return msgs.map(m => m?.method === 'tools/call' ? String(m.params?.name || '?').slice(0, 60) : '').filter(Boolean).join(',') || '?'; };
+  // A JSON-RPC id as the SDK's own Map sees it: 7 and "7" are different keys there, so they are different here.
+  const rpcIdKey = (id) => `${typeof id}:${String(id)}`;
+  const rpcRequestIdKeys = (body) => (Array.isArray(body) ? body : [body]).filter((m) => m && typeof m.method === 'string' && m.id !== undefined && m.id !== null).map((m) => rpcIdKey(m.id));
+  const rpcCancelledIdKeys = (body) => (Array.isArray(body) ? body : [body]).filter((m) => m && m.method === 'notifications/cancelled' && m.params && m.params.requestId !== undefined && m.params.requestId !== null).map((m) => rpcIdKey(m.params.requestId));
   const GET_STREAM_MAX = Math.max(1, Number(process.env.MCP_GET_STREAM_MAX || 64));
   let openGetStreams = 0;
   const streamStats = () => ({ open: openGetStreams, max: GET_STREAM_MAX, lifeMs: GET_STREAM_MS });
@@ -604,8 +608,44 @@ const inflightNameOf = (body) => { const msgs = Array.isArray(body) ? body : [bo
       ? setTimeout(() => { if (res.writableEnded) return; console.error(`[mcp] tools/call open past ${MCP_CALL_WALL_MS}ms — ending the response (${inflightNameOf(req.body)})`); try { res.end(); } catch {} }, MCP_CALL_WALL_MS)
       : null;
     if (wall && typeof wall.unref === 'function') wall.unref();
+    // ── A REQUEST ID REUSED WHILE STILL IN FLIGHT ORPHANED THE FIRST CALL'S STREAM UNTIL THE WALL (2026-11-04) ─────
+    // The SDK routes a response to its HTTP stream through ONE per-transport map keyed by the CLIENT's JSON-RPC id
+    // (_requestToStreamMapping in webStandardStreamableHttp.js). A second POST carrying an id that is still in flight
+    // on the same session OVERWRITES that entry: the first call's result is written to the SECOND stream (which then
+    // closes), the second call's result finds no mapping and is dropped, and the first POST's stream never receives
+    // anything, so it sat open until the wall above ended it with an empty body. Measured on prod as exactly that
+    // shape: a Cursor tools/call held 600s with a sibling POST from the same client answered in milliseconds
+    // (billing_status 2026-11-03T14:22:09.334Z + .336Z; three such pairs within 3s at 07:21Z), and reproduced
+    // locally against this mount — two concurrent tools/call with id 7 → one 200 in ~0.4s, one held to the wall.
+    // The spec forbids the reuse ("MUST NOT have been previously used by the requestor within the same session"),
+    // but refusing it would fail one of the user's calls; so a colliding request WAITS for the earlier one to end
+    // and then runs normally. Both run (as they already did), each gets its own result, on its own stream.
+    // Released when the response closes as well as when handleRequest settles, so a stream ended by the wall or a
+    // client abort can never leave the id held. Pinned by tools/mcp-request-id-reuse-check.mjs.
+    const idKeys = rpcRequestIdKeys(req.body);
+    const inflight = (entry.inflight ||= new Map());
+    if (idKeys.some((k) => inflight.has(k))) {
+      console.error(`[mcp] request id ${idKeys.filter((k) => inflight.has(k)).join(',')} reused while in flight on one session (${entry.client || '?'}) — queued behind the first (${inflightNameOf(req.body)})`);
+      for (let k = idKeys.find((x) => inflight.has(x)); k; k = idKeys.find((x) => inflight.has(x))) await inflight.get(k).done;
+      if (res.writableEnded || res.destroyed) { if (wall) clearTimeout(wall); return; } // the wall or the client ended it while it waited
+    }
+    let release = () => {};
+    const rec = { res, done: new Promise((r) => { release = r; }) };
+    for (const k of idKeys) inflight.set(k, rec);
+    const free = () => { for (const k of idKeys) if (inflight.get(k) === rec) inflight.delete(k); release(); };
+    res.once('close', free);
     try { await mcpCtx.run({ token, remote: true, client: entry.client || '', firstRun: entry.firstRun || null }, () => entry.transport.handleRequest(req, res, req.body)); }
-    finally { if (wall) clearTimeout(wall); }
+    finally { if (wall) clearTimeout(wall); free(); }
+    // ── A CANCELLED CALL'S STREAM IS ENDED, BECAUSE THE SDK WILL NEVER WRITE TO IT (2026-11-04) ──────────────────
+    // On notifications/cancelled the SDK aborts the handler and, per the spec, sends NO response for that request —
+    // and nothing else ends the SSE stream that was waiting for one, so a client that cancels without aborting its
+    // own fetch (Cursor does not abort it, by its own staff's account) held that POST open until the wall.
+    // Reproduced locally: tools/call id 9, then notifications/cancelled {requestId: 9} → the call held to the wall.
+    // The client has already given up on that id, so ending the response is what it would have done itself.
+    for (const k of rpcCancelledIdKeys(req.body)) {
+      const r = inflight.get(k);
+      if (r && !r.res.writableEnded) { console.error(`[mcp] request ${k} cancelled by the client (${entry.client || '?'}) — ending its stream`); try { r.res.end(); } catch {} }
+    }
   });
 
   console.error(`[mcp-remote] mounted at ${BASE || '(set HERMOSO_PUBLIC_URL)'}/mcp`);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "hermoso",
-  "version": "0.1.503",
+  "version": "0.1.505",
   "mcpName": "io.github.hermoso-ai/hermoso",
   "description": "AI marketing agent and AI ad generator, run from your own AI agent. 1182 tools. No markup on models on Starter and up. Publishing, scheduling, ad campaign management, comments, DMs and analytics cost no credits on any plan; Free includes 10 posts a month and every paid plan posts without a limit. AD PLATFORMS: Meta, Google Ads, TikTok Ads, LinkedIn Ads, Reddit Ads, X Ads, Pinterest Ads, Snapchat Ads, Microsoft Advertising, Apple Search Ads, ChatGPT Ads and AppLovin Ads, plus product feeds in Google Merchant Center. PUBLISHING AND SCHEDULING: Facebook, Instagram, Threads, TikTok, YouTube, X, LinkedIn, Pinterest, Bluesky, Telegram, WordPress, Discord, Slack, Whop and Google Business Profile. INSTAGRAM DM AUTOMATIONS: a keyword comment, a DM, a story reply or an ig.me link gets an automatic private reply from the brand. AD RESEARCH: the Meta, Google and LinkedIn ad libraries plus organic TikTok, Instagram, YouTube, Threads and Reddit. ANALYTICS: Google Analytics 4, Google Search Console and every connected platform's own post and campaign insights. Also brand onboarding, 50+ image and video generation models, ad scoring, competitor teardowns, Google Drive and OneDrive, a CLI and installable Claude skills.",
   "type": "module",