RelayPay v1.0.1 — Hardening Release

RelayPay v1.0.1 — Hardening Release

RelayPay v1.0.1 ships the post-v1.0.0 hardening batch: one scheduler instead of a broker fleet,
a cluster of verified correctness fixes, batched hot-path queries, and five security-posture
items — with /api/v1, idempotency replay bytes, SDK behavior, and every immutable journal
preserved exactly as shipped in v1.0.0.

Highlights:

• one broker-less scheduler (apps/worker/poller.py) now owns every background batch — provider
  recovery, webhook materialization and delivery, reconciliation, payouts, subscription recovery,
  inbound webhooks, and settlement forecasts — time-gated in-process with SKIP LOCKED claim
  semantics and lease tokens; Celery, Redis, and their dependencies are removed, and the fix
  surfaced and repaired a silently failing Kafka producer configuration that had left outbox
  events unpublished;
• verified correctness cluster: settlement questions now FAIL with a recorded reason when the
  model provider fails instead of staying stuck in PROCESSING; failed connector verifications
  persist their UNAVAILABLE observation; concurrent settlement-question creation, webhook
  acceptance, and workflow-run idempotency replay recover from races instead of 500ing;
  dispute packages invalidated between approval and submission fail closed with an audit
  observation; the login rate limiter no longer lets anonymous callers consume an org's budget
  and prunes expired keys;
• performance: payment list pages fetch authorizations and captures in two batched queries; the
  settlement loop runs one grouped pending-refund aggregate, three hoisted ledger-account
  lookups, and a running receivable balance instead of a full balance derivation per capture;
  admin settlement lists and settlement answers batch their per-row lookups; request-log
  retention prunes probabilistically (~1% of writes) instead of sorting the whole table per
  request; unbounded admin lists gained a default cap of 500 rows;
• security posture: pagination cursor MAC keys are domain-separated from the API-key pepper;
  GET /api/session/me is read-only (no per-render session-row write); unknown-email logins pay
  a fixed-cost argon2 verification so timing no longer reveals account existence; the Python
  image runs as a non-root relaypay user; the unauthenticated /metrics and worker metrics
  ports are documented with the network boundary they assume;
• documentation updated across architecture, deployment, operations resilience proofs,
  observability, and limitations for the scheduler consolidation and the rate-limit trust
  caveat.

This is synthetic INR portfolio software. It handles no real money, identity, merchant, banking,
or website data. Every merchant site, dispute, recovery case, and evaluation fixture is a
deterministic synthetic artifact. No deployment or hosting is included.