Abdul Moiz | CTO @FollowPay @CodingwithMagic

@piotr_minkowski Worth adding a rule that agents never edit applied Flyway/Liquibase migrations, only add new ones. Rewriting V12 passes locally on a fresh DB and then fails checksum validation on every env that already ran it. Easy thing for an agent to "fix".

@askalphaxiv Same pattern as long-lived services leaking state. The fix there is checkpoint + restart, and it maps well: persist only distilled findings and open hypotheses to a store, then start a fresh context from that. Forgetting becomes a deliberate write path, not truncation.

@SciFi The failure mode with compaction is silent: the summary drops a constraint like "don't touch the migration" and the agent violates it 40 steps later. Keep commitments in a separate pinned list that never gets summarized, and diff it before and after each compaction.

@tpschmidt_ One org bus also means one shared blast radius. PutEvents throttling from a noisy account now hits everyone, and a sloppy rule pattern can match events from accounts it was never meant to see. Pin every rule on account + source, and keep a DLQ per target.

Fix: send Cache-Control: private, no-store on anything per-user. Check CDN rules that override origin headers. Keep public and per-user data on separate paths. Test with two accounts and watch the cache status header (CF-Cache-Status, X-Cache).

Mechanism: /api/me went out with Cache-Control: public, max-age=60, or a CDN "cache everything" rule matched the path. The cache key is the URL. Your session cookie isn't part of it. The first user's response gets stored. Everyone after that gets a HIT.

User B loads /api/me and gets User A's profile. The auth check is fine. The request never reached your server. The CDN answered it from cache.

Fix: keep the default work_mem modest. Raise it only for known heavy jobs with SET LOCAL. Watch temp_files / temp_bytes (or log_temp_files). Shrink sorted row width. Don't confuse this with maintenance_work_mem (VACUUM / CREATE INDEX).

Mechanism: Postgres gives every session its own work_mem for sorts and hashes. Staging: one query, the sort fits in RAM. Prod: N concurrent queries each try to grab work_mem. Pressure, then temp files on disk.

Why does the same ORDER BY fly in staging and crawl in prod? Nothing changed in the query. The box just has a lot more sessions running at once.

Fix: the app should close first. Set app/client idle (or server keep-alive) shorter than the proxy/LB idle timeout. Align LB + app + upstream keep-alive. Idempotent GETs: retry once on connection reset / broken pipe.

Mechanism: Proxy/LB idle fires first (many default around 60s) and drops the keep-alive. Your app or client still holds that socket in its pool. Reuse it: connection reset, broken pipe, or a 502 from the next hop.

Your load balancer's idle timeout is shorter than your app's keep-alive. The LB closes the socket. The app still thinks it's open. Next request on that connection: intermittent 502 or connection reset.

@rseroter @lizziematusov Fits what review agents see: the diff. The bugs they miss tend to live outside it, like a migration that locks a hot table, a retry that isn't idempotent, or a changed default a caller relies on. Feeding the agent the schema and call sites matters more than a better prompt.

@RaulJuncoV Routing and consistency meet at read replicas. Route a user's read to a lagging replica right after their write and they see stale data. Pin reads to the primary for a short window after a write, or carry the commit LSN and only read from a replica that has replayed past it.

@K8sArchitect Prebuilt images fix boot time, but a major Postgres version bump still can't be an image swap: the data directory format changes, so you need pg_upgrade or logical replication to a new instance. Keep the PG major version out of the base image rollout path.

@techNmak The reconcile step is where it bites. If an embedding index sits beside the source of truth, a deleted or superseded fact keeps getting retrieved until the index catches up. Filter by tenant and validity window in the query itself, not after ranking.

@vlad_mihalcea The gotcha with proxies: equals()/getClass() checks. A lazy proxy is a subclass, so getClass() != Entity.class breaks equality, and touching it outside the session throws LazyInitializationException. Base equals on a business key and use instanceof.

What to do: Ballpark: SELECT reltuples::bigint FROM pg_class WHERE relname = 'orders'; (VACUUM/ANALYZE keep it fresh) Filtered: read rows= from EXPLAIN. UI: fetch 21 rows to know there's a Next. Or count a LIMIT 1001 subquery and show "1,000+".

Why there's no stored count: MVCC. Every row version carries visibility info, so two transactions at the same moment can see different totals. There's no single number to keep. count(*) reads every row, or every index entry on all-visible pages. LIMIT 20 stops at 20.

The list page pulls 20 rows off an index and comes back quick. Then it asks for the "Showing 1-20 of N" total, and that's the slow part. Postgres doesn't store a row count. Every count(*) goes and counts.