Example failure: https://neon-github-public-dev.s3.amazonaws.com/reports/pr-6471/7733161123/index.html#/testresult/abd05685d6e4707a

This test is exercising both size enforcement and backpressue, with a size limit of 30MB and the backpressure settings at the test defaults (max_replication_write_lag of 15MB).

From the compute side, postgres is indeed writing >30MB:

PG:2024-01-31 22:44:12.975 GMT [244895] LOG:  checkpoint complete: wrote 95 buffers (74.2%); 0 WAL file(s) added, 0 removed, 3 recycled; write=0.001 s, sync=0.001 s, total=0.001 s; sync files=0, longest=0.000 s, average=0.000 s; distance=47663 kB, estimate=47663 kB; lsn=0/437A9D0, redo lsn=0/437A9D0

The test is running in about 1 second, so we're reliant on the backpressure: if left to chance, it's unlikely that the pageserver would ingest data and update logical sizes. My hunch would be that something is going wrong with backpressure in the compute/safekeeper interaction.