#363 deduped node enrollment on machine_id, but the predicate it lands on is
lastHeartbeatAt / provenLiveAt. That means a host that enrolls or registers
but never heartbeats is never deduped.
relaycast-cloud#91 measured 74% of rows as never having heartbeated. So
#363 addresses a meaningfully narrower slice of the refill than its brief
assumed — roughly the 26% that do heartbeat.
This is not a defect in #363. The lane raised it explicitly rather than widening
its own PR, which was the right call, and it was held out of scope pending a
ruling.
The question: should never-heartbeated rows be deduped too, and on what
evidence? They are the majority of the table, so whatever the answer, it decides
whether the refill problem is actually closed.
Constraint worth carrying in: a registration field is not a liveness field.
#363's own review threads landed on exactly this — provenLiveAt < liveCutoff
does not prove a broker is not live, and lastHeartbeatAt can be in the future
while provenLiveAt is stale. Any dedupe keyed on never-heartbeated rows needs a
positive signal, not the absence of one.
Filed by Chief from lane-machineid-0902's escalation during the 2026-09-03
overnight run. Original context: principals/khaliq/workstreams/ in the chief
repo.
#363deduped node enrollment onmachine_id, but the predicate it lands on islastHeartbeatAt/provenLiveAt. That means a host that enrolls or registersbut never heartbeats is never deduped.
relaycast-cloud#91measured 74% of rows as never having heartbeated. So#363 addresses a meaningfully narrower slice of the refill than its brief
assumed — roughly the 26% that do heartbeat.
This is not a defect in #363. The lane raised it explicitly rather than widening
its own PR, which was the right call, and it was held out of scope pending a
ruling.
The question: should never-heartbeated rows be deduped too, and on what
evidence? They are the majority of the table, so whatever the answer, it decides
whether the refill problem is actually closed.
Constraint worth carrying in: a registration field is not a liveness field.
#363's own review threads landed on exactly this —provenLiveAt < liveCutoffdoes not prove a broker is not live, and
lastHeartbeatAtcan be in the futurewhile
provenLiveAtis stale. Any dedupe keyed on never-heartbeated rows needs apositive signal, not the absence of one.
Filed by Chief from
lane-machineid-0902's escalation during the 2026-09-03overnight run. Original context:
principals/khaliq/workstreams/in the chiefrepo.