[dbccpage]

🤖 Generated with Claude Code

Why

test_production_read_contention_during_publication[bounded] was flaky on main. The bounded worker published one generation per WAL transaction, about 13 per second, while the writer commits 20 per second. The backlog kept growing until the 30 s catch_up limit ran out.

What

• PostgresSource.peek_many(identity, offset, max_transactions) reads up to N complete, already committed transactions from the slot in one pg_logical_slot_peek_changes call. It is bounded by:

  • the per-poll byte limit (a running octet_length sum; the first row is always read, so an oversized row is still refused by name);
  • the cumulative event limit.

  Offsets must strictly increase, or it raises source_gap_or_reorder. peek() is now peek_many(..., 1).

• ProductionCatalog.apply_many(...):

  • restores each binding's checkpoint once;
  • ingests the transactions in order;
  • publishes one generation, one signed head and one slot ack, at the last LSN.

  A binding freezes at the first transaction it cannot apply, which matches per-transaction behaviour. apply() is now a one-element apply_many.

• Identity.

  • A single transaction keeps wal:<lsn>:<xid> and its old hash.
  • A group gets wal:<lsn>:<xid0>..<xidN>:<n>, with a hash taken over the ordered (offset, txn-hash) list. So a replayed group is a duplicate, not a new generation.

• PostgresWorker(max_coalesce=64) accepts values from 1 to 1024. Anything else raises invalid_coalesce_limit.

Trade-off: intermediate commits inside a group are never published. Readers see the group's end state, which is the strict worker's behaviour too.

Evidence (local; no Actions minutes spent)

check	result
tests/test_production_coalesce.py (new)	11 passed. Coalesced output equals per-transaction output, and so do ids, order/gap refusals, the event cap, replay dedupe, truncate mid-group, and limit validation
full suite pytest --ignore=tests/production_native.py	2295 passed, 8 skipped (18 min)
mypy smplcache	clean (40 files)
black --check	clean
native test_production_read_contention_during_publication on PG16 + wal2json + Redis cluster	strict and bounded pass; bounded 3/3 at about 30.8 s, commit_to_visible p95 0.59–0.69 s
control: same native test with max_coalesce=1	still fails "did not catch up within 30 seconds" (p95 13.7 s), so the fix is the coalescing and not luck

https://claude.ai/code/session_0194kAmYv4pLMyrspzKEWExZ

---

Generated by Claude Code