chore: release v0.7.0

[eggai-release-bot]

Release v0.7.0

Fixed

• Redis subscribe(..., retry_on_idle_ms=...) without max_records read
  every waiting entry in one XREADGROUP (no COUNT). All of them entered
  the consumer's PEL at once and were handled one by one, so an entry queued
  behind slow handlers went idle past retry_on_idle_ms before it started,
  and the reclaimer re-delivered it: the handler ran twice, _retry_count
  climbed (up to the DLQ) without a failure, a large backlog came back as one
  reply, and other replicas got nothing to do. max_records now defaults to
  1 when retry_on_idle_ms is set (not with batch=True), on the main and
  the retry stream. An explicit max_records is kept. This means one
  XREADGROUP per entry: setups that relied on the unbounded read for
  throughput with small, fast messages can set max_records explicitly.
• RedisTransport now dials its background clients (the PEL reclaimer, the group
  monitor, and the delete-on-ack client) with the broker's own connection settings,
  instead of a hand-maintained whitelist of forwarded kwargs. The whitelist silently
  dropped everything outside it, so against a server that needs authentication the
  background clients connected unauthenticated and were rejected
  (AuthenticationError: HELLO must be called with the client already authenticated)
  even while the broker connected fine — and db= / ssl= / client_name diverged
  too (e.g. the reclaimer scanned db 0 while the broker ran on db 3). Now username,
  password, db, ssl, credential_provider (ACL users and rotating tokens such
  as Azure Managed Redis / Microsoft Entra ID) and the resilience kwargs all match the
  broker, including when a pre-built broker= is supplied.
  Requires faststream >= 0.7 — on 0.6.0 RedisBroker(url, credential_provider=…)
  (and password=) raises TypeError.
• The group monitor no longer dies on a transient connection or auth failure
  (AuthenticationError is a ConnectionError, not a ResponseError, so it escaped
  the loop's handler): a failed cycle is logged and retried next interval, by when
  redis-py has reconnected and the credential provider has re-authenticated. A dying
  monitor previously left disconnect() re-raising and skipping reclaimer/broker/
  delete-client shutdown.
• The PEL reclaimer no longer leaks a Redis client on each connect(): a second
  connect() on a shared transport reuses the existing client instead of replacing
  it without closing the old one.

---

After merging, the release will be automatically tagged and published to PyPI.

[github-actions]

QualOps Code Quality Analysis

Status: ⚠️ WARNINGS - Medium severity issues found

Summary

• Total Issues: 1
• Critical: 0 🔴
• High: 0 🟠
• Medium: 1 🟡
• Low: 0 🟢
• Files Analyzed: 2

🟡 Medium Issues (1)

• sdk/pyproject.toml:64 - bug
  The ruff dev dependency version range >=0.14.4,<0.17.0 is invalid — Ruff uses a 0.x.y versioning scheme where the current stable series is 0.4.x–0.9.x; version 0.14.x does not exist, making this constraint unmatchable or unintentionally permissive.

📊 Full Report

View detailed report

---

Powered by QualOps