Wake Substrate post-#10404 hardening: idempotency + duplicate deduplication
Context
During the bidirectional smoke test of the wake substrate post-#10404 merge, Claude (@neo-opus-4-7) empirically discovered two distinct bugs in the wake infrastructure related to idempotency and duplicate deduplication.
Bug 1: Bootstrap Idempotency Miss
Calling manage_wake_subscription({action: 'bootstrap'}) when a subscription already exists for the tuple (agentIdentity, trigger, harnessTarget) should return status: 'existing' and avoid creating a duplicate. Instead, the action created a duplicate sub (e.g., WAKE_SUB:e5f96999 alongside existing WAKE_SUB:ca08d381) populated with the new template metadata.
Possible causes:
- The
db.nodes.items iteration in WakeSubscriptionService.mjs:bootstrap failed to surface the old sub (potential cache miss).
- The
trigger/harnessTarget shape on the old sub differs from the template post-load.
- Flawed tuple-matching logic.
Bug 2: Duplicate-Wake Delivery
A single A2A message (MESSAGE:626881c7) generated TWO wake notifications for the receiving agent, both citing the exact same subscription ID (Subscription: WAKE_SUB:ca08d381).
Possible causes:
- The Bridge daemon poll-loop iterates
trace × sub pairs without strict per-(sub, trace) deduplication before osascript/prompt injection.
- The Coalescing engine flushed twice within the 30s window.
add_message created two SENT_TO edges for the same MESSAGE id.
Proposed Solution
- Idempotency Fix: Audit and patch
WakeSubscriptionService.mjs:bootstrap to correctly identify existing subscriptions for the target tuple, preventing the generation of duplicate subscription nodes.
- Deduplication Fix: Introduce a
(sub, trace) deduplication map/set in bridge-daemon.mjs (or the coalescing logic) before invoking the hardware interrupt/wake script.
Note: The duplicate WAKE_SUB:ca08d381 is currently active and intentionally being kept alive by Claude (@neo-opus-4-7) for live-reproducible testing. Do not forcibly unsubscribe it until the fix is developed and validated against it.
Wake Substrate post-#10404 hardening: idempotency + duplicate deduplication
Context
During the bidirectional smoke test of the wake substrate post-#10404 merge, Claude (
@neo-opus-4-7) empirically discovered two distinct bugs in the wake infrastructure related to idempotency and duplicate deduplication.Bug 1: Bootstrap Idempotency Miss
Calling
manage_wake_subscription({action: 'bootstrap'})when a subscription already exists for the tuple(agentIdentity, trigger, harnessTarget)should returnstatus: 'existing'and avoid creating a duplicate. Instead, the action created a duplicate sub (e.g.,WAKE_SUB:e5f96999alongside existingWAKE_SUB:ca08d381) populated with the new template metadata.Possible causes:
db.nodes.itemsiteration inWakeSubscriptionService.mjs:bootstrapfailed to surface the old sub (potential cache miss).trigger/harnessTargetshape on the old sub differs from the template post-load.Bug 2: Duplicate-Wake Delivery
A single A2A message (
MESSAGE:626881c7) generated TWO wake notifications for the receiving agent, both citing the exact same subscription ID (Subscription: WAKE_SUB:ca08d381).Possible causes:
trace × subpairs without strict per-(sub, trace)deduplication beforeosascript/prompt injection.add_messagecreated twoSENT_TOedges for the same MESSAGE id.Proposed Solution
WakeSubscriptionService.mjs:bootstrapto correctly identify existing subscriptions for the target tuple, preventing the generation of duplicate subscription nodes.(sub, trace)deduplication map/set inbridge-daemon.mjs(or the coalescing logic) before invoking the hardware interrupt/wake script.Note: The duplicate
WAKE_SUB:ca08d381is currently active and intentionally being kept alive by Claude (@neo-opus-4-7) for live-reproducible testing. Do not forcibly unsubscribe it until the fix is developed and validated against it.