fix(pam): cap recording chunk size and batch live uploads

[bernie-g]

Description 📣

Postgres session recordings could get too big to upload once a session ran a while, and long sessions also piled up thousands of tiny chunks. This caps the chunk size and batches uploads so neither happens.

Type ✨

• Bug fix
• New feature
• Improvement
• Breaking change
• Documentation

Tests 🛠️

Ran a gateway recording to Postgres locally: a big backlog now splits into capped chunks that upload fine, and a continuous session that used to make ~50 chunks/sec batches down to a couple.

---

• I have read the contributing guide, agreed and acknowledged the code of conduct. 📝

[linear]

PAM-240

[infisical-review-police]

💬 Discussion in Slack: #pr-review-cli-257-fix-pam-cap-recording-chunk-size-and-batch-live-uploads

Posted by Review Police — reviews, comments, new commits, and CI failures will stream into this channel.

[greptile-apps]

Greptile Summary

This PR fixes two related problems with Postgres session recordings: chunks could grow unboundedly large (causing upload failures), and a continuous session would emit one tiny chunk per event rather than batching. It adds a 512 KB plaintext cap for Postgres (where ciphertext is base64'd inline into the request body) and introduces a hasMore signal in readFromOffset so the flush loop drains only genuine backlog and stops at the live write edge.

• chunk_uploader.go: introduces pamPostgresMaxPlaintextBytes = 512 * 1024; S3 sessions keep the existing 64 MB cap.
• uploader.go: extends readFromOffset to return a hasMore flag (true only when the cap was hit with at least one record still pending), and updates flushSession to pick the right cap per backend and break the drain loop once caught up to the live edge.

Confidence Score: 4/5

Safe to merge; the chunk-size cap and batching logic are correct and the change is well-scoped to Postgres sessions.

The hasMore semantics are correct: newOffset is only advanced when a record is accepted into entries, so the rejected record is always re-read on the next iteration. The only gap is that the oversized-chunk warning in EncryptAndQueueChunk still fires at the S3 64 MB threshold for all backends — a monitoring blind spot but no correctness impact.

The warning threshold in EncryptAndQueueChunk (chunk_uploader.go line 223) is the only item worth a second look.

Important Files Changed

Filename	Overview
packages/pam/session/chunk_uploader.go	Adds pamPostgresMaxPlaintextBytes (512 KB) cap constant for Postgres chunks; oversized-chunk warning in EncryptAndQueueChunk still compares against the S3 64 MB limit.
packages/pam/session/uploader.go	Adds hasMore return value to readFromOffset to distinguish backlog from live-edge; flushSession selects per-backend chunk cap and stops draining once at the live write edge. Logic is correct.

Comments Outside Diff (1)

1. packages/pam/session/chunk_uploader.go, line 223-225 (link)

   Oversized-chunk warning doesn't reflect the Postgres-specific cap

   The guard here compares against pamRecordingMaxPlaintextBytes (64 MB) for all backends. For Postgres sessions, flushSession now caps at pamPostgresMaxPlaintextBytes (512 KB), so if that cap were ever bypassed this warning would be silent until the payload reached 128× the intended limit. Since secrets.StorageBackend is already fetched a few lines below, the check could use pamPostgresMaxPlaintextBytes when secrets.StorageBackend == storageBackendPostgres, which would make on-call alerting actionable for the right threshold.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

_{Reviews (1): Last reviewed commit: "fix(pam): cap recording chunk size and b..." | Re-trigger Greptile}

[veria-ai]

PR overview

All previously flagged issues have been addressed. No open security concerns remain on this pull request.

Security review

No open security issues remain on this pull request.

Fixed/addressed: 1 · PR risk: 0/10