The Notification That Fired Twice
A simple web app in ODC lets a Requester submit a request and an Approver approve or reject it. On status change to Approved, a server action sends an email to the Requester. Testing shows the email sometimes arrives twice, and once arrived for a request that was still Pending. The approval screen has an Approve button wired to a client action that calls a server action, which updates the entity and then sends the email. A user double-clicked Approve on a slow connection. Separately, a developer added a second email send inside the entity's OnUpdate event 'for safety.' There are 15 approvers and roughly 200 requests per week.
1. Identify both causes of the duplicate email and the cause of the email for a still-Pending request.
Read the worked answer
Duplicate cause one: the Approve button is not guarded against double submission, so two client actions fire, each calling the server action, each updating status and sending. Duplicate cause two: the email is sent in two places - the server action and the entity's OnUpdate event - so a single approval can trigger both. The still-Pending email is a different bug: the OnUpdate event fires on any update to the record, not only status changes, and if the send logic there does not check that the new status is Approved, an unrelated edit (or an update that races the status write) sends mail while status is still Pending. The event is the wrong place for business logic that depends on a specific transition.
2. Propose a corrected design for sending the approval email exactly once.
Read the worked answer
Remove the email send from the OnUpdate event entirely; entity events are for data-integrity side effects, not user-facing notifications tied to a transition. Keep one send, in the server action, and make the whole operation idempotent: (1) in the server action, re-read the request inside the same transaction and check its current status; if it is already Approved, return without sending; (2) update status; (3) send the email; (4) if the send fails, record a failure flag rather than silently swallowing it. Guard the client side too: disable the Approve button on first click and re-enable on response, so a double-click cannot produce two calls. Because the server re-checks status, even a racing double call results in one email.
3. How would you test that exactly-once behaviour holds, given 200 requests a week?
Read the worked answer
Three targeted tests, not volume. (1) Double-submit test: fire the approval call twice in quick succession against the same request and assert exactly one email and one status transition. (2) Transition test: update an unrelated field on a Pending request and assert no email is sent - this catches the OnUpdate regression. (3) Failure test: force the email step to fail and assert the request status and failure flag are consistent, so the failure is visible rather than lost. Run these on every change to the approval flow. Two hundred requests a week is small enough that a bug like this reaches real users within days, so the tests need to catch it before release, not rely on production volume to reveal it.