Ceiling on the PCM data a recovery will assemble: 384 MiB covers an hour of 48 kHz mono PCM16
(345.6 MB) with headroom. Shard sizes are client-controlled (the GraphQL body limit is 50 MB, so one
shard can be ~37 MB) and gaps are filled with silence, so without this a session owner could make the
janitor allocate gigabytes. Checked against listed sizes, running actual bytes, and the assembled size.
It caps the data, not the process's memory: the shard buffers are still held while the WAV is
assembled (2x), and storage drivers can copy on read (the S3 driver copies each shard once more), so
peak memory for one recovery is up to about three times this: two 288 MB recoveries raised the API
process's RSS by 730 MB and 920 MB.
Ceiling on the PCM data a recovery will assemble: 384 MiB covers an hour of 48 kHz mono PCM16 (345.6 MB) with headroom. Shard sizes are client-controlled (the GraphQL body limit is 50 MB, so one shard can be ~37 MB) and gaps are filled with silence, so without this a session owner could make the janitor allocate gigabytes. Checked against listed sizes, running actual bytes, and the assembled size.
It caps the data, not the process's memory: the shard buffers are still held while the WAV is assembled (2x), and storage drivers can copy on read (the S3 driver copies each shard once more), so peak memory for one recovery is up to about three times this: two 288 MB recoveries raised the API process's RSS by 730 MB and 920 MB.