What causes "Feed body too large" in koala73/worldmonitor?

Increase the feed size cap in the rss-proxy configuration if legitimately large feeds must be supported.

Feed body too large

Error message

Feed body too large

What it means

The RSS proxy streams feed bodies through a bounded reader that tracks a byte cap. When a single RSS item is wider than the cap, there is no well-formed prefix worth keeping, so fetchRssResponse throws 'Feed body too large' as a hard failure instead of returning truncated, malformed XML. Smaller overflows are handled by slicing and closing open elements; this error is reserved for the unc salvageable case.

Solutions

Increase the feed size cap in the rss-proxy configuration if legitimately large feeds must be supported.
Drop or exclude the offending feed source from the aggregation list.
Ask the feed publisher to split or trim oversized item content (e.g. full-article HTML in CDATA).
Pre-check the feed with a HEAD request for Content-Length and skip feeds exceeding the cap.

Defensive patterns

Strategy: try-catch

Validate before calling

const head = await fetch(feedUrl, { method: 'HEAD' });
const len = Number(head.headers.get('content-length') || 0);
if (len > MAX_FEED_BYTES) skipFeed(feedUrl);

Try / catch

try { const feed = await fetchRssResponse(url); ... } catch (e) { if (e.message === 'Feed body too large') { markFeedOversized(url); return cachedFeed ?? null; } throw e; }

Prevention

Set a Content-Length pre-check with HEAD before streaming
Keep per-item content bounded at the publisher level
Cache the last good snapshot so an oversized feed degrades gracefully
Alert on feeds that repeatedly exceed the cap instead of failing silently

When it happens

Trigger: Fetching an RSS feed whose response stream exceeds the configured byte cap while the accumulated data has not yet reached a valid item boundary (keepTo < 0), i.e. one enormous <item> larger than the entire allowed budget.

Common situations: A publisher emitting a feed with huge embedded content/CDATA blobs in one item; a misconfigured or malicious feed serving gigantic single entries; proxying a feed endpoint that ignores size limits.

Understand the failure class

Background: payload too large / request exceeds maximum size: why libraries cap bytes and how to fix oversize payloads — this error's family across 50 libraries.

Related errors

AI-assisted analysis of koala73/worldmonitor@e586b8b4b8 (2026-09-22). Data as JSON: /api/errors/6578d7f56bcd2294. Report an issue: GitHub.

Appendix: source

Thrown at api/rss-proxy.js:175

        ITEM_CLOSE_PATTERN.lastIndex = scannedTo;
        for (let m = ITEM_CLOSE_PATTERN.exec(result.data); m; m = ITEM_CLOSE_PATTERN.exec(result.data)) {
          items += 1;
          keepTo = m.index + m[0].length;
          if (items >= MAX_FEED_ITEMS) break;
        }
        scannedTo = Math.max(keepTo, result.data.length - ITEM_CLOSE_SEAM);

        if (items >= MAX_FEED_ITEMS || bytes > MAX_FEED_BYTES) {
          bounded = true;
          break;
        }
      }
      result.data += decoder.decode();
      if (bounded) {
        // A single item wider than the byte cap leaves nothing well-formed to
        // keep, so that stays a hard failure.
        if (keepTo < 0) throw new Error('Feed body too large');
        const kept = result.data.slice(0, keepTo);
        result.data = kept + closeOpenElements(kept);
        void reader.cancel().catch(() => {});
      }
      return result;
    })()]);
  } catch (error) {
    controller.abort();
    // Cancellation can itself stall. Request it, but never extend the deadline.
    void reader?.cancel(error).catch(() => {});
    throw error;
  } finally {
    clearTimeout(timer);
    reader?.releaseLock();
  }
}

class RssProxyPolicyError extends Error {

View on GitHub (pinned to e586b8b4b8)