Reaper 3.3.2 repairs state-prioritized run listings
Reaper fixes repair-run listings and supplies missing Astra migrations. The changes concern the scheduler's own stored state and the information operators use to manage repairs.
A repair dashboard has to keep unfinished work visible even when the history of completed runs is much larger. Reaper 3.3.2, released on June 22, fixes problems listing repair runs with state priorities. It also adds missing Astra storage migrations and includes further storage refactoring.
These are changes to the repair-management tool, rather than a new Cassandra repair protocol. Reaper maintains its own record of repair work. A listing problem can consequently affect what an operator sees without establishing that the underlying database repair has the same defect.
I find Cassandra most interesting where distributed operation is a real application requirement. Repair management is part of the operational work that comes with that choice. A tool's presentation of unfinished work matters because operators need to distinguish current activity from historical results.
Reaper has state of its own
The README shipped with 3.3.2 describes Reaper as a centralized, stateful repair tool. It supports segmented repairs and can run repairs on different nodes concurrently. Scheduling is part of the tool's functionality.
Its architecture includes a database containing system state, a REST API, and a command-line client. Communication with Cassandra nodes uses JMX. There are therefore at least two kinds of state to understand, the database's repair work and the management tool's representation of that work.
That representation includes repair runs and their states. A list used for operations needs to choose which records to return, particularly when the caller requests a limit. Sorting a small set of already selected historical records cannot recover an active run excluded by the selection step.
This explains why state priority belongs in storage and retrieval as well as in presentation. A useful ordering needs the relevant records to reach the part of the program that orders them. The release fixes issues across that route.
Selection and ordering need compatible rules
The listing repair change updates state-prioritized retrieval and associated acceptance tests. Its changes include limiting the addition of fallback run identifiers and correcting a segment-count query. These are separate pieces of the result assembled for an operator.
A result limit is a concrete contract. Returning more records than requested can increase the cost of building status objects. Applying a limit before considering the desired priorities can instead omit the work the view is intended to emphasize. The implementation has to account for both selection and size.
The release's RepairRunService contains a comparator that places nonterminated runs before terminated runs. Within the same termination category, it compares run identifiers. The actual distinction is therefore broader than a promise that only the RUNNING state receives attention.
That detail matters when describing the feature to users. Unfinished work and actively executing work are related categories, but they are not interchangeable labels. The code's termination check determines the grouping used by this ordering function.
The change also adjusts tests that exercise listing limits and states. These tests provide evidence that the work concerns the returned repair view. They should not be paraphrased as a benchmark or as proof that repairs execute faster.
Missing migrations affect a different database path
The Astra migration change adds two scripts to Reaper's Astra backend. One adds a host_id UUID column to repair_run. The other creates an index on the repair-run state column in repair_run_by_cluster_v2.
These are schema changes for Reaper's storage. The name of a Cassandra cluster being repaired does not determine which schema migrations the Reaper process needs. A deployment also has to account for where the management tool stores its own records.
The state index is particularly relevant context for prioritized listings, because the storage representation includes the state used in retrieval. Its release note lists the migrations as missing additions, rather than describing a new user-visible repair algorithm. The appropriate claim is that the backend receives schema it needs for the tool's stored state.
The same change updates the Astra backend instructions for credentials. That documentation belongs to configuring Reaper's storage connection. It should not be confused with the credentials used to manage a Cassandra node over JMX.
Operator visibility depends on management correctness
My preference is for a repair tool to make unfinished work identifiable without requiring an operator to reconstruct it from unrelated logs. That requires correct stored records and a listing that respects their states. A dashboard is useful only to the extent that its selection and ordering match the work it describes.
Reaper 3.3.2 addresses those obligations through a listing correction and backend migrations. The release does not promise a shorter repair interval or a change to Cassandra's consistency behavior. It improves the management software that selects repair records, constructs their status, and presents the work operators need to follow.