Task
Observe a real $DIG receipt producing a notification, on a real machine. This is the acceptance bar for #479 that the code fix does not meet.
The loop runs this itself. It is NOT a request for the user to test something.
Why this ticket exists separately
dig-node#480 fixes the cause and is proven in both directions by test — injecting the overshoot fails the historical probes, injecting main's behaviour fails the live one. Both gate rounds returned PASS.
But nobody has watched a $DIG arrival raise a toast, and both gates said so explicitly rather than letting a green suite stand in for it. A test proves the ordering logic; it does not prove the feature works. §2.6's bar is a person watching it run on a real machine.
The two observations, and the second is the one that catches a regression
- A live $DIG receipt produces exactly one notification, naming $DIG with the right amount. Send $DIG to a node's operator wallet from a wallet the loop controls; mainnet spends for a requested task are in scope.
- A wallet WITH $DIG history installs this build and stays silent. This is the direction the first fix attempt got wrong — it would have announced every historical receipt as new, which is worse than the original bug. A run that only checks (1) cannot see that regression.
Also verify while the harness is up
- Exactly one toast per arrival, not one per coin. A payment split across several coins in one block must coalesce.
- The upgrade residual, which is real and untested: rows already staged-but-not-promoted at upgrade time default to silent, so a genuinely pending arrival could be missed once, on the upgrade only. The gate ruled this unrecoverable by migration (the fact was never recorded and the baseline has already advanced past those coins) and self-draining. Confirm the scope is as narrow as claimed.
Acceptance
Evidence gathered by the loop, not by asking a person: a screenshot or captured notification payload for (1), and a stated quiet interval with the wallet's $DIG history size for (2). Cite the node version the observation was made on.
Do not
Do not close #479 on this ticket's strength alone if either observation fails — reopen the cause instead.
Context
Cause: a CAT lands at a derived outer puzzle hash, so it reaches coins only via promote_cat_admission, which runs after record_arrivals has advanced the arrival watermark past it. XCH lands at a watched bare p2 hash and is written before the advance. The fix records, at staging time, whether the coin was news when first seen.
Task
Observe a real $DIG receipt producing a notification, on a real machine. This is the acceptance bar for #479 that the code fix does not meet.
The loop runs this itself. It is NOT a request for the user to test something.
Why this ticket exists separately
dig-node#480 fixes the cause and is proven in both directions by test — injecting the overshoot fails the historical probes, injecting main's behaviour fails the live one. Both gate rounds returned PASS.
But nobody has watched a $DIG arrival raise a toast, and both gates said so explicitly rather than letting a green suite stand in for it. A test proves the ordering logic; it does not prove the feature works. §2.6's bar is a person watching it run on a real machine.
The two observations, and the second is the one that catches a regression
Also verify while the harness is up
Acceptance
Evidence gathered by the loop, not by asking a person: a screenshot or captured notification payload for (1), and a stated quiet interval with the wallet's $DIG history size for (2). Cite the node version the observation was made on.
Do not
Do not close #479 on this ticket's strength alone if either observation fails — reopen the cause instead.
Context
Cause: a CAT lands at a derived outer puzzle hash, so it reaches
coinsonly viapromote_cat_admission, which runs afterrecord_arrivalshas advanced the arrival watermark past it. XCH lands at a watched bare p2 hash and is written before the advance. The fix records, at staging time, whether the coin was news when first seen.