[Rt-commit] rt branch, 4.4/previewscrips-race, repushed

[Shawn Moore]

The branch 4.4/previewscrips-race was deleted and repushed:
       was c6859e39029c7f3b8a652f74f5d46c0ce178581d
       now 8862bd94d3ddc84ac858f36cff2a032e51fdf67c

 1:  e36364c !  1:  db0a61d Add a test showing transaction deadlocks with concurrent ticket updates
    @@ -44,7 +44,7 @@
             ok 9 - GroupMembers agrees
             ok 10 - CachedGroupMembers agrees
         
    -    On mysql, the outcome is worse -- deadlock does not abort the
    +    On MySQL, the outcome is worse -- deadlock does not abort the
         transaction, it merely causes that statement to fail, with a gentle
         suggestion to restart the transaction.  Because of bugs propagating
         this error up, this becomes a mostly-silent corruption of database
 2:  3018528 =  2:  4701ed9 Propagate Delete failures up correctly
 3:  01dca64 =  3:  9c39310 Minor formatting fixes
 4:  65fd2b5 =  4:  01b4ee4 Remove a redundant variable
 5:  6283b7d !  5:  efe128e Remove an unnecessary "safety" check
    @@ -2,7 +2,7 @@
     
         Remove an unnecessary "safety" check
         
    -    RT::Principal->Load does sQL escaping properly, and SQL will error if
    +    RT::Principal->Load does SQL escaping properly, and SQL will error if
         passed anything that is not an integer.  No other method does this
         manner of verification.
     
 6:  a542708 =  6:  18a88f4 Remove duplicated logging on ->Delete failure
 7:  92edf4a !  7:  6c0cf77 Remove misleading or unhelpful comments
    @@ -1,6 +1,6 @@
     Author: Alex Vandiver <alex at chmrr.net>
     
    -    Remove misleading or unhelpful comments.
    +    Remove misleading or unhelpful comments
     
     diff --git a/lib/RT/CachedGroupMember.pm b/lib/RT/CachedGroupMember.pm
     --- a/lib/RT/CachedGroupMember.pm
 8:  6c852c3 !  8:  04aeb4c Take a real lock in SetOwner
    @@ -12,7 +12,7 @@
         the ticket update page) to do all of the above steps within a single
         database transaction, which is then rolled back.  Because of this
         overarching transaction, locks are held across different stages of the
    -    update -- which is an notable difference from the non-DryRun updates.
    +    update -- which is a notable difference from the non-DryRun updates.
         
         Together, these can lead to deadlocks when updating owners and
         recording correspondence.  The timeline is as follows:
    @@ -68,6 +68,8 @@
         this would block the ticket update at step 13, until PreviewScrips
         completed its work and rolled its transaction back.  This suffices to
         resolve the new tests in `t/ticket/race.t`.
    +    
    +    Fixes: I#32381
     
     diff --git a/lib/RT/Ticket.pm b/lib/RT/Ticket.pm
     --- a/lib/RT/Ticket.pm
 9:  3367f72 !  9:  06925ed Factor out, and use, an atomic transaction method on Tickets
    @@ -3,10 +3,10 @@
         Factor out, and use, an atomic transaction method on Tickets
         
         The previous commit introduced a pattern which is likely useful
    -    elsewhere -- that of running a ticket in a manner that is guaranteed
    +    elsewhere -- that of updating a ticket in a manner that is guaranteed
         to be atomic.
         
    -    Factor out this behavior into a new method, which is mirror to DryRun
    +    Factor out this behavior into a new method, which mirrors DryRun
         in some ways.  For additional safety when used with DryRun, the first
         SQL statement of both methods is the lock on the Ticket row; this
         forces any code within them to run serially.
10:  c6859e3 = 10:  8862bd9 Switch to using ->Atomic for all ticket updates via the UI