tree 02c953f97afa8b1dac8c816534ec8e82babb3c8f
parent e490c2778bde2de9de8f0ef67b16f1d5440f0d93
author Luca Milanesio <luca.milanesio@gmail.com> 1696890747 +0100
committer Luca Milanesio <luca.milanesio@gmail.com> 1697465557 +0100

Do not rely on async/wait for synchronous fetch replication

Before this change, the request for a sync FetchAction was triggering
an async schedule of a replication task, with a replication delay of
zero.

The consequence was the blocking of the client thread for an async
replication that, potentially, could have been stuck in the queue
waiting for other async replication to complete.
Scheduling a replication task does not guarantee that the fetch will
start immediately because it is influenced by the whole logic behind the
replication queue mechanism:
- waiting for the runway
- being aggregated with an existing pending task
- appended to the bottom of the replication queue

When the client requests a sync replication, it typically has other
client resources associated and locked that won't tolerate the async
execution. Faking a sync execution with async/wait for a Future to
complete would not allow the client resources to be released.

Skip the replication queue altogether and rely on the direct
FetchOp execution when the client REST-API FetchAction call has
requested synchronous execution.

Bug: Issue 304123378
Change-Id: Ia9171dc9525f2543ba16b1eb78308b0580839cbf