swarm-nats: set max_payload to 8 MiB explicitly

The swarm queue's rendered settings never named max_payload, so it ran
on nats-server's upstream default of 1 MiB. That default is about to
be too small: the broker is going to carry agent terminal rows
(whole TermMsg bodies) published as complete messages rather than
split, and a publish over the limit does not truncate — the server
answers -ERR 'Maximum Payload Violation' and closes the connection,
dropping the row.

Set max_payload = 8388608 explicitly in the settings merge, with a
comment on what it bounds and what bounds it (max_pending, which
nats-server refuses to start past). Add a module-eval case that reads
the rendered container config so a future edit that drops or shadows
the key fails eval instead of surfacing as a dropped row in
production.

Refs #3805
This commit is contained in:
atlas 2026-09-12 21:16:28 +02:00 committed by mara
commit 09d502ea34
2 changed files with 23 additions and 0 deletions

View file

@ -674,6 +674,18 @@ in
issuerKey = deployCfg.nats.calloutIssuerPublicKey;
}
// {
# The most a single publish may be, in bytes, before the
# server answers `-ERR 'Maximum Payload Violation'` and
# closes the connection — not a truncation, a dropped row
# and a reconnect. This queue is about to carry agent
# terminal rows published whole rather than split, so
# upstream's own default is sized to lose one of those
# rather than merely shorten it. Bounded from above by
# `max_pending`: nats-server refuses to start once this
# exceeds it, and widening that ceiling instead costs
# memory per connection, so this stays comfortably under it.
max_payload = 8388608;
# The monitoring endpoint, which is what the exporter below
# reads. `//` adds a key `calloutBlocks` does not produce
# (`accounts`, `authorization`) — checked, because a shallow