rqlite 6.8 exposes readiness and preserves numeric display
The CLI gains a .ready command over the existing readiness endpoint. Its JSON decoder also preserves number tokens instead of converting generic values through floating point.
An operator's client must describe the server accurately. It needs a useful answer about whether requests can proceed, and it must preserve the values returned by a query. The November 9 release of rqlite 6.8.0 improves both parts of the CLI. It adds access to /readyz and fixes numeric display during JSON deserialization, as recorded in the tagged changelog.
Neither change introduces a new storage engine feature. They concern the observations people make through the client. That is still substantive behavior. A database can return the intended value while a client reformats it unhelpfully, and a running process can remain unable to satisfy a meaningful readiness condition.
I value rqlite's small operational interface, so useful CLI observations matter to me. They make it possible to ask a specific question without reconstructing the HTTP request manually. Their scope needs to be clear enough that an answer does not imply a stronger guarantee than the implementation checks.
The CLI asks the existing readiness endpoint
The 6.8.0 CLI implementation registers .ready. Its handler constructs a GET request to the configured protocol, host, port, and prefix followed by /readyz. If credentials were supplied to the CLI, it attaches Basic Auth after checking their format.
An HTTP 200 response prints ready. Every other received status prints not ready. Request construction and transport errors return errors instead of one of those normal status messages. This is a compact interface over the endpoint, with deliberately little detail in the displayed answer.
curl 'http://localhost:4001/readyz'
That HTTP request illustrates the existing endpoint the new command uses. The command adds convenience within an interactive CLI session. The cumulative changelog dates the endpoint itself to 6.5.0 in September, so November should not be described as its server-side introduction.
Readiness has a particular definition
The HTTP service at the release tag first checks the caller's readiness permission and requires GET. It obtains the leader's Raft address, then asks the cluster service for that node's API address. A successful lookup yields HTTP 200 and a leader-ok response. Without a usable leader address or successful lookup, the ordinary result is HTTP 503.
This checks more than whether the process has opened an HTTP socket. It depends on the service identifying and reaching the leader through its cluster communication path. That makes it useful when a node is running but cannot currently identify a reachable leader endpoint.
The handler does not execute an application SQL statement or commit a new write as its readiness test. Its success therefore should not be expanded into proof that every subsequent operation will succeed. It is an observation of the documented lookup path at the time of the request.
The CLI's status summary is also intentionally coarse. An authorization rejection and an unavailable leader can both appear as not ready, since both are non-200 responses. The endpoint's actual HTTP status contains information the short CLI message does not retain. An operator investigating that result can distinguish the request's permissions from the cluster's availability by inspecting the underlying response.
JSON decoding now retains numeric tokens
The CLI's shared response parser creates a JSON decoder and calls UseNumber before decoding. The generic JSON display path does the same. This keeps numbers in generic decoded values as JSON numbers instead of immediately passing them through the decoder's ordinary floating-point representation.
The query-display code stores row values in interface-valued arrays and formats a cell with Go's generic value formatter. The decoder's choice therefore affects what the user sees. Preserving a number token lets that display path retain its textual numeric form without first choosing a floating-point approximation for a generic field.
This change belongs to the client parsing path. It does not widen SQLite's integer range or alter how a numeric expression executes inside the engine. A database result and its presentation can differ because there is an additional serialization and decoding boundary between them.
I prefer the parser to preserve that information until a consumer deliberately chooses a numeric interpretation. A display command does not need to perform arithmetic merely to print an identifier or count. Converting generic values unnecessarily gives it another opportunity to change the representation before the operator reads it.
The implementation applies UseNumber before decoding both query responses through the shared parser and generic JSON used by CLI diagnostics. That makes the correction broader than a special formatter for one table column. It addresses the point where generic JSON numbers enter the client's in-memory representation.
Version 6.8.0 consequently improves two distinct observations. .ready summarizes a specific leader-address reachability check through the existing endpoint. Numeric decoding preserves number tokens for display. Both changes make the CLI's account of the service more useful while leaving the actual SQL execution and consensus rules with the server.