fix(rabbitmq): reserve message metadata in the retrieval response budget

Author: waleedlatif1

apps/docs/content/docs/en/integrations/rabbitmq.mdx

@@ -38,6 +38,7 @@ Sim talks to RabbitMQ over its **Management HTTP API** — the same interface be
 - The user you authenticate as needs the **`management` tag** at minimum, plus read and write permissions on the virtual host you target. Administrative operations require broader permissions.
 - Publishing and reading messages over the HTTP API is **convenient but not a high-throughput transport** — RabbitMQ opens a new connection per request. It is well suited to workflow-rate traffic, inspection, and operational automation; a service consuming thousands of messages per second should use an AMQP client instead.
 - Queue statistics such as message and consumer counts are **collected on an interval**, so a queue declared moments ago may report them as empty until the broker's next sample.
+- Reading messages is **bounded per call** so one retrieval cannot exceed Sim's response limit. A batch is capped at 50 messages, payloads are truncated (each message reports whether it was), and a large batch shortens payloads further. AMQP properties and headers are returned in full — the broker offers no way to truncate them — so retrieving several messages carrying very large headers may still hit the limit; lower the count if that happens.
 {/* MANUAL-CONTENT-END */}
 
 
@@ -84,7 +85,7 @@ Retrieve messages from a RabbitMQ queue. Defaults to requeueing the messages so
 | `count` | number | No | Maximum number of messages to retrieve, from 1 to $\{MAX_MESSAGE_COUNT\}. Defaults to 1 |
 | `ackmode` | string | No | How retrieved messages are handled: ack_requeue_true \(default, leaves messages in the queue\), ack_requeue_false \(removes them\), reject_requeue_true, or reject_requeue_false |
 | `encoding` | string | No | auto \(default\) returns readable text where possible, base64 always returns base64 |
-| `truncate` | number | No | Truncate payloads longer than this many bytes. Defaults to $\{DEFAULT_TRUNCATE_BYTES\} and is capped at $\{MAX_TRUNCATE_BYTES\}, and lowered further when a large count would push the response past the transport limit. Each message reports whether it was truncated |
+| `truncate` | number | No | Truncate payloads longer than this many bytes. Defaults to $\{DEFAULT_TRUNCATE_BYTES\}, capped at $\{MAX_TRUNCATE_BYTES\}, and lowered further at high counts so the whole batch stays inside the response limit. Each message reports whether it was truncated |
 
 #### Output
 

apps/sim/blocks/blocks/rabbitmq.ts

@@ -357,7 +357,7 @@ Return ONLY valid JSON - no explanations, no markdown code blocks.`,
       title: 'Message Count',
       type: 'short-input',
       placeholder: '1',
-      description: 'Maximum number of messages to retrieve, up to 100',
+      description: 'Maximum number of messages to retrieve, up to 50',
       condition: { field: 'operation', value: 'rabbitmq_get_messages' },
     },
     {

apps/sim/tools/generated/tool-metadata.ts

@@ -19,38 +19,58 @@ const ACK_MODES = new Set([
 
 /**
  * The broker applies no upper bound of its own to `count`, so a single call could pull an
- * unbounded number of messages of unbounded size into memory. Both dimensions are bounded here:
- * `count` caps how many messages come back, and `truncate` caps each payload broker-side so the
- * oversized bytes are never transferred at all. The truncate default matches the management UI's own.
+ * unbounded number of messages into memory, and the shared tool transport rejects any response
+ * body over 10MB before a tool ever sees it. Both dimensions are bounded here.
  */
-const MAX_MESSAGE_COUNT = 100
+const MAX_MESSAGE_COUNT = 50
 const DEFAULT_TRUNCATE_BYTES = 50_000
+const MIN_TRUNCATE_BYTES = 1_024
+const MAX_TRUNCATE_BYTES = 1_000_000
 
 /**
- * Payload budget for one call. The shared tool transport rejects any response body over 10MB,
- * and `count * truncate` alone could exceed that — base64 payloads inflate a further 4/3 on top,
- * before JSON escaping. Keeping the combined payload under this budget means a large `truncate`
- * degrades to shorter payloads rather than failing the whole retrieval at the transport cap.
+ * Budget for one retrieval, kept under the transport's 10MB cap with room for the JSON envelope.
  */
-const MAX_TOTAL_PAYLOAD_BYTES = 4_000_000
-const MAX_TRUNCATE_BYTES = 1_000_000
+const RESPONSE_BUDGET_BYTES = 8_000_000
+
+/**
+ * Per-message allowance for AMQP properties and headers. `truncate` bounds the payload only —
+ * the broker returns properties in full — so the budget has to reserve space for them rather
+ * than assume they are small. This figure is RabbitMQ's default `frame_max`, which bounds the
+ * content header frame carrying a message's properties, so any message published by a standard
+ * AMQP client fits inside it.
+ *
+ * The one case this cannot cover is a message published through the management HTTP API itself,
+ * which bypasses `frame_max` and accepts properties up to that API's ~10MB request-body limit.
+ * Retrieving several of those can still exceed the transport cap and surfaces as a response-size
+ * error; the remedy is a lower `count`.
+ */
+const PER_MESSAGE_METADATA_RESERVE_BYTES = 131_072
+
+/** base64 payloads inflate 4/3 on the wire before JSON escaping. */
+const BASE64_INFLATION = 4 / 3
 
 function resolveCount(count: number | undefined): number {
   if (typeof count !== 'number' || !Number.isFinite(count)) return 1
   return Math.min(Math.max(Math.trunc(count), 1), MAX_MESSAGE_COUNT)
 }
 
 /**
- * Resolves the per-message byte limit actually sent to the broker, bounded both per message and
- * across the whole batch so the response always fits inside the shared transport cap.
+ * Resolves the per-message payload limit sent to the broker. The whole batch — payloads plus the
+ * reserved metadata allowance for every message — is held inside {@link RESPONSE_BUDGET_BYTES},
+ * so asking for a large `truncate` alongside a large `count` yields shorter payloads rather than
+ * a retrieval that fails at the transport cap.
  */
 function resolveTruncate(truncate: number | undefined, count: number | undefined): number {
+  const messages = resolveCount(count)
   const requested =
     typeof truncate === 'number' && Number.isFinite(truncate)
       ? Math.max(Math.trunc(truncate), 1)
       : DEFAULT_TRUNCATE_BYTES
-  const budgeted = Math.floor(MAX_TOTAL_PAYLOAD_BYTES / resolveCount(count))
-  return Math.max(Math.min(requested, MAX_TRUNCATE_BYTES, budgeted), 1)
+
+  const payloadBudget = RESPONSE_BUDGET_BYTES - messages * PER_MESSAGE_METADATA_RESERVE_BYTES
+  const perMessageBudget = Math.floor(payloadBudget / messages / BASE64_INFLATION)
+
+  return Math.max(Math.min(requested, MAX_TRUNCATE_BYTES, perMessageBudget), MIN_TRUNCATE_BYTES)
 }
 
 export const rabbitmqGetMessagesTool: ToolConfig<
@@ -95,7 +115,7 @@ export const rabbitmqGetMessagesTool: ToolConfig<
       type: 'number',
       required: false,
       visibility: 'user-only',
-      description: `Truncate payloads longer than this many bytes. Defaults to ${DEFAULT_TRUNCATE_BYTES} and is capped at ${MAX_TRUNCATE_BYTES}, and lowered further when a large count would push the response past the transport limit. Each message reports whether it was truncated`,
+      description: `Truncate payloads longer than this many bytes. Defaults to ${DEFAULT_TRUNCATE_BYTES}, capped at ${MAX_TRUNCATE_BYTES}, and lowered further at high counts so the whole batch stays inside the response limit. Each message reports whether it was truncated`,
     },
   },
 

apps/sim/tools/rabbitmq/get_messages.ts

@@ -212,7 +212,7 @@ describe('rabbitmq_get_messages bounds', () => {
   })
 
   it('caps a count the broker would otherwise accept unbounded', () => {
-    expect(body({ queue: 'orders', count: 100_000 }).count).toBe(100)
+    expect(body({ queue: 'orders', count: 100_000 }).count).toBe(50)
     expect(body({ queue: 'orders', count: 0 }).count).toBe(1)
     expect(body({ queue: 'orders', count: 25 }).count).toBe(25)
   })
@@ -420,20 +420,35 @@ describe('rabbitmq_get_messages response budget', () => {
       number
     >
 
-  it('keeps the whole batch under the shared transport response cap', () => {
-    const TRANSPORT_CAP = 10 * 1024 * 1024
-    for (const count of [1, 10, 50, 100]) {
+  const TRANSPORT_CAP = 10 * 1024 * 1024
+  // `truncate` bounds the payload only — the broker returns AMQP properties in full — so the
+  // worst case a batch can produce is every message also carrying a full content header frame.
+  const FRAME_MAX = 131_072
+
+  it('keeps payloads plus worst-case message metadata under the transport cap', () => {
+    for (const count of [1, 2, 10, 25, 50, 100]) {
       const sent = body({ queue: 'q', count, truncate: 100_000_000 })
-      // base64 inflates payloads by 4/3 before JSON escaping, so budget against the worst case.
-      expect(sent.count * sent.truncate * (4 / 3)).toBeLessThan(TRANSPORT_CAP)
+      expect(sent.count * (sent.truncate * (4 / 3) + FRAME_MAX)).toBeLessThan(TRANSPORT_CAP)
     }
   })
 
+  it('caps the batch so reserved metadata alone cannot exhaust the budget', () => {
+    expect(body({ queue: 'q', count: 100_000 }).count).toBe(50)
+    expect(body({ queue: 'q', count: 100_000 }).count * FRAME_MAX).toBeLessThan(TRANSPORT_CAP)
+  })
+
   it('caps a single oversized truncate request', () => {
     expect(body({ queue: 'q', truncate: 100_000_000 }).truncate).toBe(1_000_000)
   })
 
-  it('leaves a reasonable truncate untouched', () => {
+  it('leaves a reasonable truncate untouched at a low count', () => {
     expect(body({ queue: 'q', truncate: 20_000, count: 5 }).truncate).toBe(20_000)
   })
+
+  it('shortens payloads rather than failing the retrieval when count is high', () => {
+    expect(body({ queue: 'q', truncate: 50_000, count: 2 }).truncate).toBe(50_000)
+    const high = body({ queue: 'q', truncate: 50_000, count: 50 }).truncate
+    expect(high).toBeLessThan(50_000)
+    expect(high).toBeGreaterThanOrEqual(1_024)
+  })
 })