Title | Can lose Bugzilla changes in rare race condition |
Status | suspended |
Priority | essential |
Assigned user | Nick Barnes |
Organization | Ravenbrook |
Description | If a Perforce job is changed, and the matching Bugzilla bug is changed in a conflicting way in the same poll period, and the change to the Bugzilla bug takes place in the same second as the next replication poll starts, then the change in Bugzilla is lost. The change in Bugzilla is deliberately left until the next replication poll, to avoid a much more common conflict (job000235). So the change in Perforce is replicated over the change in Bugzilla, and when the next poll tries to replicate the Bugzilla change it is too late. This will be rare or very rare, especially for poll periods of the default duration (10 seconds). However, it is serious when it happens, because it silently breaks our conflict policy. |
Analysis | To fix this, we need either (a) to keep a lot more information in the P4DTI auxiliary tables in the Bugzilla database or (b) to patch Bugzilla. There isn't enough information currently in the Bugzilla database to distinguish between changes which take place just before a poll and those which take place just afterwards (this was job000235). And leaving the changes before the poll until the next poll is dangerous (this job). This could be a simple patch to Bugzilla: adding a 'known to be up-to-date' field to a Bugzilla bug (or the p4dti_bug table) which is cleared when Bugzilla touches the bug. The replicator would set this field after replication or migration. Then changed_entities would be a lot simpler. However, we have avoided changing the Bugzilla schema until now. |
How found | inspection |
Evidence | Lots of thinking by GDR and NB, 2001-06-27. |
Observed in | 1.1.1 |
Introduced in | 1.0.0 |
Created by | Nick Barnes |
Created on | 2001-06-27 12:58:11 |
Last modified by | Nick Barnes |
Last modified on | 2018-07-05 17:27:39 |
History | 2001-06-27 NB Created. 2018-07-05 NB Suspended because the P4DTI is obsolete. |