Bart 87f9f61f13 perf: Shape a stream event once per API version, not per subscriber ...

Shaping a message into a notification copies it whole, and every subscriber
of a stream receives the same event, so the shaping runs once per subscriber
where one copy per API version is enough. Introduce `StreamBroadcast`, which
holds the shape its event takes for each version it is asked for, so the
second subscriber on a version is handed the copy the first one's shaping
made. The fourteen stream publish sites move from `sendShaped` onto it. The
class arrives here rather than a commit earlier because the cache is what
gives its members state to read: a pass-through holding nothing fails
`readability-convert-member-functions-to-static`, and `.clang-tidy` sets
`WarningsAsErrors: "*"`.

What the cache can hold bounds where it may be used. A message built for the
one subscriber it is going to must not travel this way, only shapes being
held: the `account_history` loop, the backfill sender and the
account-history failure lambda each tell a subscriber something only that
subscriber gets, so they stay on `sendShaped`.

A subscriber named by a url receives what it is given as the parameters of an
`event` call, so `sendTo` asks `wantsNotifications` for the reason
`sendShaped` does, sends it the message unshaped whatever its version, and
holds no shape for it. No client can observe any of this, which a case
reading one ledger event from two version 3 subscribers and one version 1
subscriber pins.

2026-10-10 20:02:30 +09:00

..

xrpl

perf: Shape a stream event once per API version, not per subscriber

2026-10-10 20:02:30 +09:00