P4DTI issue job000366

TitleSome replicator failures may leave things inconsistent
Assigned userNick Barnes
DescriptionIf the replicator dies for some reason, it can leave some inconsistent state which is not cleared up on a restart.
Most replicator actions are idempotent, in the sense that it notices if it has not completed a replication poll and will perform it again, on the same jobs and issues, making them consistent. However, some replicator actions are not idempotent.
For example, the Bugzilla integration performs some operations which involve multiple writes to multiple Bugzilla tables (e.g. when updating a bug, it writes to bugs, bugs_activity, and p4dti_bugs_activity), and because MySQL is not transactional it is possible for some of these updates to persist when others do not. Since the bugs_activity table is not checked against the bugs table, this example of the problem will not get corrected on a restart.
For another example, if the replicator dies while composing a mail message, the message may well never get sent. See also job000211.
AnalysisThis is hard.
As far as I can tell on a cursory inspection, none of the inconsistencies which can be caused in this way will break Bugzilla. We should give this more than a cursory inspection.
How foundinspection
EvidenceThinking about Perforce job 6101: <http://info.ravenbrook.com/mail/2001/07/19/20-57-01/0.txt>
Observed in1.1.1
Created byNick Barnes
Created on2001-07-20 13:49:50
Last modified byNick Barnes
Last modified on2018-07-05 17:27:43
History2001-07-20 NB Created.
       2018-07-05 NB Suspended because the P4DTI is obsolete.