tree 4dfa92573ad95c1984da39a3271acf80413d47ab
parent d7cfdbc914dc18ffab985538bf392a6b9e43c547
author Luca Milanesio <luca.milanesio@gmail.com> 1593614066 +0100
committer Gerrit Code Review <noreply-gerritcodereview@google.com> 1593614066 +0000

Update git submodules

* Update plugins/replication from branch 'stable-2.16'
  to f0fb23cdf39dfb89971e6655f0e08650e14b0631
  - Fix flakiness in ReplicationIT for pending events firing
    
    Fix the shouldFirePendingOnlyToStoredUri test by making sure
    that events are NOT executed by the replication engine until
    the tests has completed the preparation phase.
    
    The Gerrit build on stable-2.16 became flaky right afterward
    the merge of the new shouldFirePendingOnlyToStoredUri test which
    highlighted the flakiness.
    
    The test wants to simulate a situation where a ref-update needs
    to be propagated to two remotes: remote1 and remote2.
    For doing so, it configures the two remotes and crates a change
    for generating the two replication tasks files on the filesystem.
    Then, it looks for the events associated for remote1 and removes
    them, so that the next replication queue startup won't find it
    and won't replicate the change to remote1.
    
    During the interval of time between the creation of the change
    and the removal of the underlying replication task on the filesystem,
    the replication task could have been executed already and the
    test failed.
    
    Make sure that the replication does not kick in by
    setting the replication timeout to Integer.MAX_VALUE at the
    beginning. Then, once the replication task file is removed on the
    filesystem, set it back to default and reload the configuration to
    trigger the firing of the events.
    
    Remove also the explicit start/stop of the replication queue, as
    the config reload is already a stop/start process and it
    automatically triggering an event replay.
    
    Change-Id: Ifd591da37e94b6ce8f281cb0404f3f3c737489f3