Skip to content
z4j docs

Changelog

Latest headline release: z4j v1.8.0.

Each package versions independently; the table below shows the current latest of every published package. The per-package history follows.

PackageLatestReleasedCategoryLicenseLinks
z4j1.8.02026-07-23UmbrellaAGPL-3.0PyPI · GitHub · Docs
z4j-bare1.8.02026-07-23CoreApache-2.0PyPI · GitHub · Docs
z4j-core1.8.02026-07-23CoreApache-2.0PyPI · GitHub
z4j-scheduler1.8.02026-07-23CoreApache-2.0PyPI · GitHub · Docs
z4j-django1.8.02026-07-23FrameworksApache-2.0PyPI · GitHub · Docs · Upstream
z4j-fastapi1.8.02026-07-23FrameworksApache-2.0PyPI · GitHub · Docs · Upstream
z4j-flask1.8.02026-07-23FrameworksApache-2.0PyPI · GitHub · Docs · Upstream
z4j-arq1.8.02026-07-23EnginesApache-2.0PyPI · GitHub · Docs · Upstream
z4j-celery1.8.02026-07-23EnginesApache-2.0PyPI · GitHub · Docs · Upstream
z4j-dramatiq1.8.02026-07-23EnginesApache-2.0PyPI · GitHub · Docs · Upstream
z4j-huey1.8.02026-07-23EnginesApache-2.0PyPI · GitHub · Docs · Upstream
z4j-rq1.8.02026-07-23EnginesApache-2.0PyPI · GitHub · Docs · Upstream
z4j-taskiq1.8.02026-07-23EnginesApache-2.0PyPI · GitHub · Docs · Upstream
z4j-apscheduler1.8.02026-07-23SchedulersApache-2.0PyPI · GitHub · Docs · Upstream
z4j-arqcron1.8.02026-07-23SchedulersApache-2.0PyPI · GitHub · Docs · Upstream
z4j-celerybeat1.8.02026-07-23SchedulersApache-2.0PyPI · GitHub · Docs · Upstream
z4j-hueyperiodic1.8.02026-07-23SchedulersApache-2.0PyPI · GitHub · Docs · Upstream
z4j-rqscheduler1.8.02026-07-23SchedulersApache-2.0PyPI · GitHub · Docs · Upstream
z4j-taskiqscheduler1.8.02026-07-23SchedulersApache-2.0PyPI · GitHub · Docs · Upstream

History by package

Section titled “History by package”

z4j

v1.8.0 (2026-07-30)

  • added: Durable bulk retry. A bulk retry is now a request you can watch rather than a fire-and-forget button. The request identity, its audit row, and the complete per-task plan commit together, so the work that will run is decided up front. Submitting the same request again returns the original outcome instead of re-expanding the filter, which matters because the set of failed tasks keeps moving. Each task is claimed once at its send edge under a fleet-wide in-flight bound, and a running retry can be paused and later resumed.
  • added: Authenticated audit chain. The audit log is signed with a key held independently of the database, so the chain stays verifiable to someone who does not trust the database operator. Existing history is classified and frozen as authenticated legacy history during the upgrade; where it cannot be classified beyond doubt the upgrade stops and asks for an explicit operator attestation rather than adopting history it cannot prove.
  • added: Issues moves into the dashboard as its own page, with ongoing and recovered filters served by brain-side filtering, and scheduler misfires now surface directly on the Schedules page.
  • added: Connection pool sizing is configurable. Pool size and overflow were fixed values, which made the brain's connection demand impossible to fit to a database server the operator does not control. Defaults are unchanged, so no existing deployment shifts on upgrade.
  • changed: Rolling upgrades are a supported configuration. The brain may run one minor version ahead of its agents, so the control plane and the fleet can be upgraded independently rather than in one window. Exercised in both directions against a real prior release.
  • fixed: Reliability hardening across delivery, agent buffering, and scheduling. Retry authority is bound to the worker generation that executes it, the agent buffer only ever adopts storage it can prove belongs to it, and the agent starts safely on filesystems that cannot lock reliably. Validated by a harness running real brain and agent processes against both supported databases.

v1.7.0 (2026-07-14)

  • added: Automation rule engine. Per-project rules watch a task or scheduler trigger and run a governed action (notify an operator, retry a task, or cancel a task), each with its own guardrails: a rolling-window circuit breaker that trips a runaway rule into notify-only, a per-project kill switch, and a dry-run mode that records what a rule would have done without touching anything. Destructive actions require an admin who has passed a fresh second-factor check, re-verified at the moment the rule fires, and every firing lands on the audit log.
  • added: Issues (failure fingerprinting). Task failures group by a stable fingerprint so the same bug across runs and engines collapses to one issue with occurrence counts, an open vs recovered split, first and last seen, and the engines affected.
  • added: Scheduler reliability. Brain-side misfire detection flags any enabled interval or cron schedule whose expected fire is past a grace window (a dead or partitioned scheduler is the usual cause) and feeds it to automation, subscriptions, and metrics. Project-wide misfires are queryable from the REST API and a new CLI, and fire-now actions are attributed to the operator who triggered them. Fire history is range-partitioned for fast retention.
  • added: MFA trust shell. A TOTP second factor via any standard authenticator app, one-time recovery codes, and an opt-in remember-this-device cookie. Enforcement is opt-in and off by default; once a user is enrolled their session must pass the second factor before general access.
  • security: The enterprise-serious hardening release. Closes a set of execution-path and step-up-authentication findings from a multi-round internal adversarial audit, plus a frontend and tooling dependency refresh. Operators are advised to upgrade.
  • changed: Verified data-safe in-place upgrade from 1.6.x on both PostgreSQL and SQLite (a populated upgrade preserved every row). The wire protocol is compatible for a rolling upgrade: upgrade the brain first, then roll the agents. Python 3.11 is the new minimum.

v1.6.9 (2026-06-23)

  • fixed: Reliability release. Eliminates a spurious shutdown-time error traceback on short-lived processes (one-shot management commands) by draining the agent runtime before the interpreter tears down its worker pool. Adds an opt-out for the liveness heartbeat on transient processes. Plus an audit-trail completeness improvement for the bulk-retry endpoint.

v1.6.8 (2026-06-08)

  • security: Follow-on security release. Closes two high-severity issues in the bulk-retry and mixed-version dispatcher paths that the Round 9 external audit surfaced on top of 1.6.7. Operators are advised to upgrade.

v1.6.7 (2026-06-07)

  • security: Security release. Addresses a high-severity issue in one engine adapter's retry surface plus supply-chain hardening across CI workflows. Operators running RQ or shared-Redis deployments are advised to upgrade.

v1.6.6 (2026-06-07)

  • security: Security release. Addresses a high-severity information-disclosure issue plus several lower-severity hardening items. Operators are advised to upgrade.

v1.6.5 (2026-05-27)

  • security: Security release closing multiple authentication, session, transport, and dependency-supply-chain hardening items. Operators are advised to upgrade.
  • changed: Password minimum length aligned at 12 characters across backend default, dashboard fallback, and operator docs.

v1.6.3 (2026-05-15)

  • security: Security release. Operators are advised to upgrade.

v1.6.2 (2026-05-14)

  • changed: Dashboard design system unified across every page: consistent headers, filter toolbars, search inputs, action buttons, empty states, and time-range pickers.
  • added: Search and state filters on the Agents, Queues, and Workers pages.
  • security: Frontend and tooling dependency refresh.

v1.6.1 (2026-05-13)

  • fixed: Dashboard bundle correction for the MFA enrollment and post-login challenge surfaces. In-place upgrade picks up the fix.

v1.6.0 (2026-05-13)

  • added: Multi-factor authentication. TOTP via any standard authenticator app (Authy, 1Password, Google Authenticator, etc.), single-use recovery codes, optional 30-day device trust. Opt-in: existing users stay unenrolled until they enable it.
  • added: Microsoft Teams notification channel. Workflows webhooks, Power Automate, and the legacy O365 connector all auto-detected at save time.
  • added: Sentry error capture, OpenTelemetry tracing, audit-log webhook forwarding, four Grafana dashboards, and a Live Activity Feed on the dashboard home.
  • changed: One bidirectional schema migration (upgrade and downgrade both safe on populated databases). No data migration required.

v1.5.1 (2026-05-12)

  • fixed: Brain memory hygiene under sustained burst load. Tunable via `Z4J_DATABASE_STATEMENT_CACHE_SIZE`.
  • added: Four new Prometheus gauges plus a Grafana dashboard so operators can verify operational health in their own environment.

v1.5.0 (2026-05-11)

  • security: Security release. Operators are advised to upgrade.
  • fixed: Task-correctness fixes around event acknowledgement, event-loop decoupling, and event deduplication.
  • fixed: Scheduler load-test fixes.

v1.4.0 (2026-05-03)

  • changed: The brain server, dashboard, REST API, audit log, and reconciliation all ship in a single `z4j` distribution. `pip install z4j` is the only install path operators need.
  • added: Engine adapters available via extras: `pip install z4j[django,celery]` for the full Django + Celery stack, plus extras for FastAPI, Flask, RQ, Dramatiq, Huey, arq, TaskIQ, APScheduler.
  • security: Security release. Operators are advised to upgrade.

z4j-bare

v1.8.0 (2026-07-30)

  • changed: Agent durability. Each process generation seals its own buffer before examining older ones, and only a buffer it can prove is exclusively held and belongs to this deployment is recovered automatically. Anything foreign or unreadable is left in place for a human rather than drained or deleted. On filesystems that cannot lock reliably the agent relocates to a private path and logs it instead of refusing to start.
  • changed: A close the agent cannot fix by reconnecting is now treated as terminal, so a rejected agent stops rather than reconnecting in a loop.

v1.7.0 (2026-07-14)

  • fixed: Agent runtime and dispatch fixes from a fleet readiness sweep, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.9 (2026-06-23)

  • fixed: Shutdown lifecycle hardening: the agent runtime now registers its teardown to run before the process worker pool is shut down, drains in-flight work deterministically, and supports a heartbeat-less mode for short-lived processes. Removes the spurious shutdown-time error noise.

v1.6.8 (2026-06-08)

  • security: Dispatcher hardening: refuses retry against a legacy RQ adapter rather than falling back to a signature that would re-open a prior pickle-deserialization issue.
  • fixed: Brain-derived task name now wins over operator-supplied values in the Huey retry path.

z4j-core

v1.8.0 (2026-07-30)

  • changed: Transport carries a versioned capability contract so the brain can tell what the connected agent is able to honour, rather than assuming. Redaction and path handling were tightened alongside it.

v1.7.0 (2026-07-14)

  • added: Failure fingerprinting support in the shared domain layer, so the same bug across runs and engines collapses to one issue.
  • changed: Python floor raised to 3.11 and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

  • changed: Python compatibility floor relaxed from 3.10/3.11 to 3.10 so adapters embedded in operator processes can install on the broader Python deployment base.

z4j-scheduler

v1.8.0 (2026-07-30)

  • changed: Schedule cursor authority. A schedule's next-fire cursor is normalised to a single cadence identity and advanced under the brain's authority, so a schedule cannot appear to be moving while never actually running. Databases that reached an affected pre-release state are repaired automatically and the repair is recorded in the immutable schedule change log.

v1.7.0 (2026-07-14)

  • added: Fire-variance metrics showing how far each fire lands from its scheduled time, and an info command that reports version, uptime, readiness, per-subsystem health and loaded-schedule count from the running service.
  • changed: Fire history is range-partitioned on PostgreSQL, so retention drops a partition instead of running a large delete. Python floor raised to 3.11.

v1.6.7 (2026-06-08)

  • changed: Python floor relaxed from 3.13 to 3.11 so the scheduler process runs on the same interpreter range as the brain.

z4j-django

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • changed: Python floor raised to 3.11 and version unified with the rest of the fleet.

v1.6.9 (2026-06-23)

  • fixed: Clean shutdown on short-lived management commands: no more spurious error traceback at process exit.

v1.6.8 (2026-06-08)

  • security: Engine-extra floor lifted so `pip install z4j-django[rq]` resolves only the hardened RQ adapter line.

v1.6.7 (2026-06-08)

  • changed: Wider Django compatibility range: installs cleanly against Django 5.0 and up with no upper cap. Operator owns their own Django security posture; the adapter no longer gates on CVE versions.

z4j-fastapi

v1.8.0 (2026-07-30)

  • changed: Version alignment with the fleet release. No functional change in this package.

v1.7.0 (2026-07-14)

  • changed: Python floor raised to 3.11 and version unified with the rest of the fleet.

v1.6.9 (2026-06-23)

  • fixed: Clean shutdown registration so the agent drains before the process worker pool is torn down.

v1.6.8 (2026-06-08)

  • security: Engine-extra floor lifted so `pip install z4j-fastapi[rq]` resolves only the hardened RQ adapter line.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest FastAPI (>=0.95) version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-flask

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • changed: Python floor raised to 3.11 and version unified with the rest of the fleet.

v1.6.9 (2026-06-23)

  • fixed: Clean shutdown registration so the agent drains before the process worker pool is torn down.

v1.6.8 (2026-06-08)

  • security: Engine-extra floor lifted so `pip install z4j-flask[rq]` resolves only the hardened RQ adapter line.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest Flask version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-arq

v1.8.0 (2026-07-30)

  • changed: Version alignment with the fleet release. No functional change in this package.

v1.7.0 (2026-07-14)

  • fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest arq version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-celery

v1.8.0 (2026-07-30)

  • changed: Retry authority is bound to the worker that executes it. The adapter advertises a versioned contract on its own live connection, so a retry cannot be handed to a colocated older worker that would run the task with empty arguments and report success. Package floors are coordinated across the fleet to match.

v1.7.0 (2026-07-14)

  • fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-07)

  • fixed: Multi-tenant cache bleed fix. Worker-stats cache moved from class scope to instance scope so two adapters in the same process no longer share state.

z4j-dramatiq

v1.8.0 (2026-07-30)

  • changed: Retry authority is bound to the worker that executes it. The adapter advertises a versioned contract on its own live connection, so a retry cannot be handed to a colocated older worker that would run the task with empty arguments and report success. Package floors are coordinated across the fleet to match.

v1.7.0 (2026-07-14)

  • fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest Dramatiq (>=1.14, <3) version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-huey

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest Huey (>=2.4, <3) version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-rq

v1.8.0 (2026-07-30)

  • changed: Retry authority is bound to the worker that executes it. The adapter advertises a versioned contract on its own live connection, so a retry cannot be handed to a colocated older worker that would run the task with empty arguments and report success. Package floors are coordinated across the fleet to match.

v1.7.0 (2026-07-14)

  • fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-08)

  • changed: Wider RQ compatibility range: now installs against RQ >=1.10 (previously >=2.8.0), with <3 cap. Captures the RQ 1.x deployed majority that the previous floor excluded.

z4j-taskiq

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • fixed: Execution-path fixes surfaced by a fleet-wide readiness sweep, plus the Python floor raised to 3.11 and the whole fleet unified at a single version so an operator no longer has to reason about per-package version drift.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest TaskIQ version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-apscheduler

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest APScheduler (>=3.8, <4) version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-arqcron

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest arq version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-celerybeat

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest Celery (>=5.3) and django-celery-beat (>=2.5) version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-hueyperiodic

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest Huey (>=2.4, <4) version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-rqscheduler

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest rq-scheduler (>=0.11) version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.

z4j-taskiqscheduler

v1.8.0 (2026-07-30)

  • changed: Aligned with the fleet release and its coordinated dependency floors, so a current adapter cannot be installed beside an incompatible dispatcher.

v1.7.0 (2026-07-14)

  • fixed: Scheduler execution-path fixes, the Python floor raised to 3.11, and version unified with the rest of the fleet.

v1.6.7 (2026-06-08)

  • changed: Wider compatibility range: now installs against the lowest TaskIQ version where every API z4j uses is present, with no upper cap. Operator-chosen primaries are no longer CVE-gated by the adapter; the operator owns their own framework security posture.