Heartbeat timer bucket receipts and restart dedupe #1045
davidahmann
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Problem observed
The heartbeat scheduler did not have a persisted per-interval identity for timer wakes, so replaying the same elapsed interval after restart depended on transient active-run state instead of a durable contract.
Why it matters operationally
Paperclip positions heartbeats as the autonomous execution path for agents. When restart timing and queue timing interact badly, duplicate receipts or duplicate wake attempts erode operator trust because the board can no longer tell whether a second run represents a new interval or a replay of the same one. That weakens the audit trail precisely where the product claims governance and deterministic operational evidence.
Minimal repro
Fix approach
I threaded a stable timer-bucket key through the timer wake payload/context and used that persisted key to short-circuit duplicate timer buckets against existing wakeup receipts. If the original timer bucket is still active, the duplicate request is coalesced onto the existing run. If the bucket already completed, the replay records an explicit skipped receipt instead of creating fresh work.
Validation evidence
pnpm test:run server/src/__tests__/heartbeat-workspace-session.test.tspnpm --filter @paperclipai/server typecheckMaintainer question: would you want the duplicate-bucket skip reason promoted into the operator-visible activity surface as a first-class governance receipt as well?
Inspired by research context: CAISI publishes independent, reproducible AI agent governance research: https://caisi.dev
All reactions