CockroachDB 20.1.3 requires admin sessions for debug endpoints
Debug HTTP handlers gain session and role checks, while changefeeds without a resolved interval flush less often. The patch addresses access control and the cost of slow downstream sinks.
A request arriving from localhost does not identify the database administrator who made it. CockroachDB 20.1.3 adds a valid admin login-session requirement to HTTP endpoints under /debug/. The June 29 release notes announce that change alongside a longer default changefeed flush interval for feeds without an explicit resolved option. Both repairs concern operational interfaces, although they solve unrelated problems.
The release catalog identifies 20.1.3 as the June maintenance release. Its debug access change supplies an identity and authorization check where a network-location restriction had previously carried the protection. Its changefeed adjustment gives slow sinks more time between flush operations instead of assuming that frequent flushing always improves delivery.
I value the explicit costs in CockroachDB's distributed design. Administrative tools need similarly explicit assumptions about access and latency. A local request and an administrator session are different facts. A shorter flush interval and faster end-to-end delivery are also different facts when the sink takes substantial time to complete each flush.
The handler checks identity and role
Ben Darnell's debug endpoint patch says the legacy handlers were previously protected only by an IP restriction to localhost. The implementation places them behind session authentication where web sessions are required. It then checks that the authenticated identity is an administrator before calling the debug handler.
The added tests distinguish anonymous access, an authenticated non-admin and an authenticated admin. The first two receive an unauthorized response, while the admin receives success. That is a useful statement of the access contract. Obtaining a session is necessary, but a session belonging to an ordinary user is insufficient.
The patch also updates a remote-debugging test to obtain an authentication cookie and attach it to requests. Automation using those handlers therefore needs to account for the session requirement. A script reaching the same host and URL can still encounter a different result after the update because the handler now evaluates who is making the request.
Debugging information has its own scope
The Advanced Debug documentation available with this release describes operational reports and cluster configuration views. It identifies reports for problem ranges, distribution and zone configuration, alongside raw status information such as sessions and logs. Some views are restricted to administrators in secure clusters, while others have different access rules.
This reinforces the need to identify the exact endpoint when diagnosing an access failure. The release changes paths beginning with /debug/. A broad statement that all monitoring now requires an admin session would exceed what the patch says. Different operational handlers can expose different information and retain their own access contracts.
For an operator, the useful evidence is the request path and the session identity associated with it. A browser page may combine several requests, and a command-line collector may call a handler directly. The visible operation's name alone does not establish which authorization check rejected it. Recording the actual handler makes the changed contract reviewable.
Flushing can consume the time needed to emit data
David Taylor's changefeed patch describes feeds to cloud storage spending too much time flushing. The earlier default came from a low-latency sink context and amounted to 200 milliseconds. A higher-latency sink could spend so much effort completing flushes that the feed struggled to keep up with the data it needed to emit.
The patch changes the fallback interval to five seconds. A specified resolved timestamp interval remains an indication of the user's latency requirement and controls the corresponding calculation. The source comment explains that a cloud storage flush can take much longer than a flush to a lower-latency sink such as Kafka.
This is a concrete throughput and latency tradeoff. Waiting longer can increase the time before buffered changes become visible downstream. It can also reduce the proportion of execution spent on frequent expensive flushes. A default that minimizes one waiting interval does not necessarily maximize the amount of useful data the pipeline delivers.
An explanation of lag therefore needs to include the operation occupying the feed. If repeated flushes dominate its execution, reducing their interval can increase that overhead instead of helping the backlog. The patch's account ties the default change to that observed mechanism. It leaves room for an explicit latency choice where the sink can support it, without assuming that every destination has the response time of the environment in which the old default was chosen.
I prefer the rationale stated in terms of the sink's actual cost. An application choosing a latency-sensitive configuration can express that requirement. A feed that leaves the option unspecified gets a fallback intended to tolerate slower destinations. That is a narrower and more useful claim than treating five seconds as a delivery guarantee for every changefeed.
A resolved timestamp is a progress statement
The change data capture documentation describes at-least-once delivery. Previously emitted versions can appear again after failures. A resolved timestamp establishes that no previously unseen row version with a lower update timestamp will arrive on that partition. That progress marker answers a different question from whether an individual record has been emitted once.
Consequently, downstream consumers need to preserve the distinction between duplicate handling and progress tracking. A repeated earlier version does not contradict the documented guarantee when it was already seen. A resolved marker is useful for determining which unseen earlier work is complete, including when records for different rows arrive through different partitions.
The flush interval adjustment changes how the implementation balances work on that delivery path. It does not replace the at-least-once contract with exactly-once delivery or make every sink equally fast. Consumers still need the documented interpretation of row versions and progress, while operators gain a default less likely to spend nearly all its time flushing to a slow destination.