| Title | Some replicator failures may leave things inconsistent |
| Status | suspended |
| Priority | essential |
| Assigned user | Nick Barnes |
| Organization | Ravenbrook |
| Description | If 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. |
| Analysis | This 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 found | inspection |
| Evidence | Thinking about Perforce job 6101: <http://info.ravenbrook.com/mail/2001/07/19/20-57-01/0.txt> |
| Observed in | 1.1.1 |
| Created by | Nick Barnes |
| Created on | 2001-07-20 13:49:50 |
| Last modified by | Nick Barnes |
| Last modified on | 2018-07-05 17:27:43 |
| History | 2001-07-20 NB Created. 2018-07-05 NB Suspended because the P4DTI is obsolete. |