atproto relay implementation in zig
zlay.waow.tech
mark DB success on did_cache hits
isDbHealthy() is a 30s freshness check on last_db_success, but the
markDbSuccess() call sites only fire on cache misses + the 10-min GC
tick. with a hot did_cache in steady state, miss rate can dip for 30+
seconds, leaving the health flag stale and tripping k8s liveness probes
even though the relay is healthy.
cache hits use DB-derived data, so they're a valid signal that the
data path is functioning. mark success on the fast path. cost is one
clock_gettime + atomic store per ingestion event (~20 ns vDSO).
the GC tick still provides real DB liveness as a backstop.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
+9
-2
+9
-2
src/event_log.zig
+9
-2
src/event_log.zig
···
432
432
/// resolve a DID to a numeric UID. creates a new account row on first encounter.
433
433
/// matches indigo's Relay.DidToUid → Account.UID mapping.
434
434
pub fn uidForDid(self: *DiskPersist, did: []const u8) !u64 {
435
-
// fast path: check in-memory cache
436
-
if (self.did_cache.get(did)) |uid| return uid;
435
+
// fast path: check in-memory cache. mark DB success even on hits —
436
+
// a hot cache means the DB-derived data path is functioning, which
437
+
// is what /_readyz cares about. without this, the 30s health window
438
+
// depends entirely on cache misses + the 10-min GC tick, which can
439
+
// gap during steady-state and trip k8s liveness probes.
440
+
if (self.did_cache.get(did)) |uid| {
441
+
self.markDbSuccess();
442
+
return uid;
443
+
}
437
444
438
445
// check database
439
446
if (try self.db.rowUnsafe(