Room server: max_posts silently capped at 32; second client cap trims without logging #142

New Issue

2026-10-27T09:35:18+01:00

adam commented

2026-10-27 09:35:18 +01:00

What we hit

Two related surprises while running room servers in production:

max_posts is silently capped. Config values above the hard limit (32, MAX_UNSYNCED_POSTS) are clamped in the constructor without a warning — room_stats then reports a different max_posts than the config says. Is the 32 cap load-bearing (sync protocol? memory budget?), or just a conservative default? We have been running a patched build with max_posts: 200 since 2026-08-18 on the Czech community mesh; the timestamp-based client sync handles the longer history fine in our usage. If there is no protocol reason, making the cap configurable (or at least logging the clamp) would help BBS-style rooms.
The client capacity is governed by two independent constants, and the second one trims clients silently with no log line. Whichever way the intended capacity is defined, a room dropping a synced client is worth an INFO/WARNING — from the client side it looks like the room simply stopped pushing.

Happy to send a PR for either once the intended semantics are confirmed.

## What we hit Two related surprises while running room servers in production: 1. **`max_posts` is silently capped.** Config values above the hard limit (32, `MAX_UNSYNCED_POSTS`) are clamped in the constructor without a warning — `room_stats` then reports a different `max_posts` than the config says. Is the 32 cap load-bearing (sync protocol? memory budget?), or just a conservative default? We have been running a patched build with `max_posts: 200` since 2026-08-18 on the Czech community mesh; the timestamp-based client sync handles the longer history fine in our usage. If there is no protocol reason, making the cap configurable (or at least logging the clamp) would help BBS-style rooms. 2. **The client capacity is governed by two independent constants**, and the second one trims clients silently with no log line. Whichever way the intended capacity is defined, a room dropping a synced client is worth an INFO/WARNING — from the client side it looks like the room simply stopped pushing. Happy to send a PR for either once the intended semantics are confirmed.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/pyMC_Repeater#142