Firefly v1.0.2

Release date: July 31, 2026

v1.0.2 focuses on explicit boundaries and failure recovery. It does not add a large web framework or change Netty's role as the primary Executor transport. Instead, rules previously buried in HTTP paths, Gateway code, plugin loading, and JDBC statements are now represented as verifiable policies, state transitions, and maintenance procedures.

Maven Central status

The source, version metadata, and publication checks are prepared for 1.0.2. Maven Central artifacts are uploaded by the tag-driven release workflow. Before upgrading, confirm that 1.0.2 is indexed in Central Portal.

Highlights

Admin HTTP security boundary

• AdminHttpPlugin now owns assembly and lifecycle only; routing, authorization, request reading, responses, auditing, and domain controllers are separate components.
• RBAC policies are attached during route registration. The authorization layer no longer infers permissions from hard-coded business paths.
• Request bodies, pagination, and batch operations have shared limits, with stable errors for malformed JSON, oversized input, and unknown routes.
• Admin HTTP still uses JDK HttpServer; Spring MVC, WebFlux, and other large web runtimes were not introduced.

Netty protocol and backpressure

• A separately published netty-protocol module provides an explicit wire model shared by Gateway and Executor Client.
• Frames use Jackson JSON codecs, not JDK native serialization.
• Gateway coordination is separated from connection lifecycle, and result persistence runs through a dedicated bounded queue.
• Saturation triggers bounded delayed retries outside Netty EventLoop threads. Exhausted retry capacity or attempts produce an observable final rejection.

Schedule and plugin compatibility

• ScheduleType identifies executable schedules. Only CRON and FIXED_RATE can enter job definitions; unknown implementations are rejected before persistence.
• Plugin API now supports API-level ranges. The current level remains 1, and older 1.x plugins remain compatible through the interface default method.
• Every enabled plugin is validated before any plugin starts, preventing partially capable nodes from joining the cluster.

JDBC consistency and failure verification

• Executor business idempotency is separated into a state machine, DAO, and transaction template.
• Claims use database time, row locks, a monotonic generation, and conditional-update fencing. An expired owner cannot complete or release a newer claim after takeover.
• PostgreSQL and MySQL tests exercise connection failure and recovery. Local builds may skip real-database tests when no external database exists, while CI retains that gate.
• The unused admin-model module and non-executable process-fault benchmark scaffold were removed. compatibility/spring-boot-consumer remains because CI actively uses it.

Controlled shard expansion

v1.0.2 adds an online expansion maintenance action, but it is not a general zero-downtime, dual-routing reshard:

• Only shard-count increases are supported; online contraction is not.
• Scheduler, Standby, and API nodes must be drained and stopped first.
• Data-plane-only Gateway and Executor nodes may stay online.
• Explicit confirmation is required, with no active executions or unfinished outbox records.
• The maintenance transaction holds the migration lock, recomputes job shards, advances cluster metadata revision, and removes stale leases.

See JDBC and HA for the operating procedure.

Upgrade checklist

1. Upgrade Maven or Gradle dependencies to 1.0.2; remain on 1.0.1 until Central indexing completes.
2. Confirm custom plugin compatibility() ranges include Plugin API level 1. A patch release alone does not require recompilation.
3. Direct Netty-module consumers should account for the new transitive netty-protocol module. Starter consumers do not declare it separately.
4. Deployments using JDBC business idempotency should compare their table with the dialect SQL under clients/executor-netty.
5. Before changing shard count, back up the database and complete the controlled-expansion drain, idle-state, and rollback checks.

Non-goals

• This release does not implement the still-undefined failure registry.
• It does not promise exactly-once execution; business side effects still need a unique key or transactional idempotency.
• Online shard contraction is unsupported, and Scheduler/API service cannot continue while the shard mapping changes.

See the complete source at the Firefly v1.0.2 tag.