This field test was against Kubernetes.
The issue was Kubernetes #138728:
https://github.com/kubernetes/kubernetes/pull/139545
The issue involved the watch cache path around initial events.
The useful diagnostic boundary was:
watch cache consistency work → read lock hold time → initial event delivery
That matters because cache paths in Kubernetes are not just storage details.
They sit between stored state and the clients watching that state.
If too much work happens while a cache lock is held, the system may still be logically correct, but the operational path can become more expensive, more blocking, or harder to scale than it needs to be.
The local repair candidate is intentionally narrow.
It does not redesign the watch cache.
It does not change the broader storage model.
It does not rewrite WatchList behavior.
The patch focuses on reducing how much work happens while the watch-cache read lock is held.
For ordered stores, the repair keeps the cheap snapshot boundary during interval construction, but defers full ordered list materialization until the interval is consumed by the watcher path.
In plain terms:
Take the necessary cache boundary under lock.
Do not do heavier list materialization there if it can be safely deferred.
The local patch touched only the watch-cache interval implementation and its focused tests.
Local validation passed for the relevant cacher tests, store tests, full cacher package tests, and diff hygiene.
- Status: draft PR opened for maintainer review
Field Test #013
- Project: Kubernetes
- Issue type: watch-cache / initial-events behavior
- Boundary: cache consistency work under lock vs bounded watcher consumption
- Result: narrow local repair candidate and focused test coverage
- Status: local proof prepared; no public PR or comment opened yet
This field test matters because it shows Scarab operating inside a major distributed systems platform.
The bug shape was not a simple crash.
It was not a UI issue.
It was not a configuration mismatch.
It was a mechanical boundary in a high-pressure cache path.
The system has to preserve cache truth, but it also has to preserve operational truth: how much work happens under lock, where state is materialized, and whether the path remains bounded enough for the workload it serves.
That is the kind of software truth boundary Scarab is built to surface.
Sometimes the important repair is not a large rewrite.
Sometimes it is moving work to the right side of the boundary.
Top comments (0)