We handled all the crazy cases such as when a delete action succeeds but contains a payload, and ended up with a failure in the simple, normal delete case! Since the resource delete event reports the component name, the event needs to be built before the resource is actually deleted. This does it right at the time the resource is set or unset.
This means the window where the event could be sent but the commit could fail is wider; but if such a thing does happen, there will be extra anomalous events in the record rather than missing ones, which seems better.
This was also causing pinga to complain that the delete action failed (even though all the commits had gone through). Seems like it was just a logging thing, however--no functionality seems to have been impacted.
We handled all the crazy cases such as when a delete action succeeds but contains a payload, and ended up with a failure in the simple, normal delete case! Since the resource delete event reports the component name, the event needs to be built before the resource is actually deleted. This does it right at the time the resource is set or unset.
This means the window where the event could be sent but the commit could fail is wider; but if such a thing does happen, there will be extra anomalous events in the record rather than missing ones, which seems better.
This was also causing pinga to complain that the delete action failed (even though all the commits had gone through). Seems like it was just a logging thing, however--no functionality seems to have been impacted.