A task can be approved successfully while its Discord notification fails. Treating those events as one result makes recovery harder to understand.
Pip Bot, also named MIH Bot in its package and documentation, separates the stored task transition from chat delivery in its shared action helpers.
Save the decision first#
Approval writes the completed status, feedback, and completion timestamp to MongoDB. Only after that does the helper attempt the Discord card update and direct message.
The durable task record therefore represents the decision even if a message cannot be delivered. A failed direct message does not undo an approval that has already been stored.
Handle delivery paths independently#
Card updates and direct messages have separate failure handling. This matters because one can succeed while the other fails: a channel message may be available while the recipient's direct messages are closed.
Logging those failures provides evidence for diagnosis. It does not itself create a durable retry queue. A future retry mechanism would need to record which delivery is pending and distinguish it from repeating the underlying task action.
Reset reminder state when reopening work#
Rejection returns the task to an active state and clears reminder counters and timestamps. Old reminder history should not silently determine the entire notification behavior of newly reopened work.
Scheduled reminders then use status, deadline, archived-project, and last-notified conditions. Their database update and message send still cross two systems.
Avoid implying atomic delivery#
MongoDB and Discord do not become one transaction because a helper calls them in sequence. The inspected implementation gives task state a clear authority and handles message errors separately.
A durable delivery record with retries would be a concrete next step. Exactly-once notification claims would require additional design and evidence beyond the current helpers.