+++ This bug was initially created as a clone of Bug #1029142 +++ Currently we remove calls from the UI even when their deletions fails and we do so without checking if the associated transaction has succeeded so we can have both situations where we've not removed some calls (bug 1029142) yet we remove them from the UI; and cases where the entire transaction can fail yet we'd happily chug along as if everything went fine.

Unfortunately, doing this would likely make the UI feel sluggish. Before going forward, we should test how slow it is to verify that the transaction completes before updating the UI. But if it does indeed slow it down significantly, I have a proposal to mitigate this: 1. Store the list of UI nodes to be deleted into an array. 2. Dispatch the transaction to delete the calls. 3. Remove the UI nodes from the call log. 4. Transaction: a. Succeeds: do nothing. b. Fails: Restore the UI nodes from the array. Display an error message. The case that the deletion fails should ideally be exceedingly rare. So it makes more sense to me to optimize for the common case. Though this would involve more work and more points of failure. A similar discussion took place in bug 1001467 for the SMS app, though it was mostly focused on performance.

(In reply to Doug Sherk (:drs) from comment #1) > The case that the deletion fails should ideally be exceedingly rare. So it > makes more sense to me to optimize for the common case. Though this would > involve more work and more points of failure. +1, let's make the common case fast and the rare case correct - we don't need the latter to be fast too, just non-confusing like it currently is.