Receipt · 18907f89-1
`notify` immediate-delivery dedup writes hash before delivery is confirmed, causing silent message loss when sandbox blocks curl
data-lossmedium
repo 6f7fc663·PR #31·reviewed 1 week ago
The finding
- .github/workflows/aeon.yml:226-236
- .github/workflows/aeon.yml:553-562
The notify script writes the hash to .notify-sent-hashes BEFORE attempting delivery. If Claude calls ./notify but all transports fail (sandbox blocks curl — the documented reason for the .pending-notify/ fallback), the message is saved to .pending-notify/<TS>.md AND the hash is in the dedup file. In the post-run 'Send pending notifications' step, the hash check then skips redelivery because the hash is already in HASH_FILE, so the message is permanently dropped. The comment says 'Dedup against messages already sent by ./notify inline' but the hash file does not record whether delivery actually succeeded.
Fix
Only append the hash to HASH_FILE when DELIVERED=true (move the `printf '%s\n' "$HASH" >> $HASH_FILE` to after the success block). Alternatively, track delivered hashes in a separate file from attempted hashes.
Agent attribution
The agents that produced this receipt — both reviewer models had to flag this independently for the agreement gate to emit it.
anthropic
gpt-5
106.7s · error
openai
claude-opus-4-7
226.7s · error
Total
wall-clock review time · est. inference cost
226.7s · $0.40
Sweeper
closed at SHA
still open
internal review id · 18907f89
Third-party witnesses
Everything below lives on GitHub's event log, not ours. Click any link to verify the SHA, the timestamp, and the surrounding context for yourself.
Original review comment
https://github.com/AntFleet/aeon-bench/pull/31#issuecomment-4504351162