You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 3530024
Browse filesBrowse the repository at this point in the historyBrowse files
fix(connectors): heartbeat a running sync and cap deletion generations apart
Review round 4 on #6909. Two regressions the guards introduced, plus two tests
that could not fail.
Counting a stale-lock reclaim as a failure turned the reaper into a one-way
ratchet for any sync that legitimately outran the TTL: the in-process path has
no duration cap, so a long self-hosted sync was reclaimed, its successful
terminal write then failed the ownership guard and was discarded, and its
failure counter never reset. Ten of those and a working connector was disabled
telling the user to reconnect.
A running sync now refreshes updatedAt every five minutes, so the reaper's
staleness predicate means "nobody is working on this" rather than "this started
a long time ago". The beat is guarded on the run's own lock, so it doubles as an
ownership probe: a run whose lock was reclaimed abandons immediately instead of
working for hours and then discarding the result.
The deletion cap summed soft and hard deletes against one ceiling sized for a
single generation, so a connector with steady churn deadlocked from its second
sync onward and got monotonically worse — the all-or-nothing hold blocked the
very hard deletes that would have drained the tombstone backlog. Hard deletes
are confirmations of removals already gated when they were soft-deleted, so each
generation now caps independently.
Both guard tests for the reaper asserted only the bookends of the rendered SQL,
leaving the comparison itself unasserted: an inverted threshold that disabled a
connector on its first hard kill passed. Both now assert the whole expression.
0 commit comments