mirror of
https://gh-proxy.org/https://github.com/klinsmaya/multica.git
synced 2026-11-11 02:46:45 +08:00
e5f976144b
Source-context cleanup (MUL-6555) ran at the top of the 30s runtime sweep tick, ahead of the stages that flip a dead runtime offline and reclaim its orphaned tasks. Both cleanup stages call the object store, so a stalled or throttled endpoint delayed runtime/task recovery: one round's work was bounded by the number of due intents rather than the batch size, because the loop counted successes, and the abandoned-capture path deleted objects on the sweeper's root context with no per-object deadline. Move both stages onto their own goroutine and ticker, bound each round with a wall-clock budget, bound the intent loop by attempts, and give every object delete a deadline. Failed deletes now record their retry backoff on a context detached from the round budget, so a round cut short cannot leave an intent claimable with no backoff and starve the rows behind it. Cleanup cadence moves from 30s to 60s; nothing here is latency-critical (intents settle for an hour, captures for 30 days). Co-authored-by: J <[email protected]> Co-authored-by: multica-agent <[email protected]>