You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A RewardCouponV2 sets its observers as if providerIsObserver then [provider] ++ optionalToList beneficiary else [] (Splice/Amulet.daml). Splice's own comment says the DSO mints with providerIsObserver = false when the provider's vetting state does not allow it, and that DSO automation later tries to make the provider an observer if the vetting state changes — unless the coupon expired first.
The reward automation reads the ACS filtered by party = decparty. A coupon with providerIsObserver = false is therefore not in that ACS at all: it cannot be seen, cannot be assigned, and expires.
Why it is worth tracking rather than fixing
Nothing in this codebase can fix it — observer sets are decided by the DSO at mint time. It is a precondition on the environment, not a defect in the automation.
But it is currently undocumented and silent, which is the actionable part:
Design §4 lists the assumptions the automation relies on and does not mention it.
run_reassign_once returns early with no log when nothing is assignable, so "this decparty has no coupons" and "this decparty has coupons the node cannot see" produce identical output — an empty log.
So a decparty could lose every reward to this and the only symptom would be an automation that looks idle.
Requirements
Record it in design §4 as an environmental precondition, alongside the beneficiary-self-mint and Mode-B-paused preconditions.
Add it to the PR/feature caveats: coupons must carry providerIsObserver = true for the automation to see them, and the decparty's vetting state is what determines that.
Make it detectable rather than silent — this is the same requirement as the reward-automation health signal (reward automation has no health signal: silent stop, failing assigns, coupons nearing expiry #278): the gap between "no coupons exist" and "coupons exist that we cannot act on" needs to be visible from outside. Cross-check against the DSO's view (PQS or scan) is the only way to see the invisible ones.
References
~/splice/daml/splice-amulet/daml/Splice/Amulet.daml — RewardCouponV2 observer clause and the providerIsObserver comment.
crates/decman/src/server/reward_automation.rs — unassigned_coupons (party-filtered ACS read), run_reassign_once (silent early return).
Summary
A
RewardCouponV2sets its observers asif providerIsObserver then [provider] ++ optionalToList beneficiary else [](Splice/Amulet.daml). Splice's own comment says the DSO mints withproviderIsObserver = falsewhen the provider's vetting state does not allow it, and that DSO automation later tries to make the provider an observer if the vetting state changes — unless the coupon expired first.The reward automation reads the ACS filtered by
party = decparty. A coupon withproviderIsObserver = falseis therefore not in that ACS at all: it cannot be seen, cannot be assigned, and expires.Why it is worth tracking rather than fixing
Nothing in this codebase can fix it — observer sets are decided by the DSO at mint time. It is a precondition on the environment, not a defect in the automation.
But it is currently undocumented and silent, which is the actionable part:
run_reassign_oncereturns early with no log when nothing is assignable, so "this decparty has no coupons" and "this decparty has coupons the node cannot see" produce identical output — an empty log.So a decparty could lose every reward to this and the only symptom would be an automation that looks idle.
Requirements
providerIsObserver = truefor the automation to see them, and the decparty's vetting state is what determines that.References
~/splice/daml/splice-amulet/daml/Splice/Amulet.daml—RewardCouponV2observer clause and theproviderIsObservercomment.crates/decman/src/server/reward_automation.rs—unassigned_coupons(party-filtered ACS read),run_reassign_once(silent early return).