Redirect replication requests when shard count is different #3789
Conversation
| @@ -174,7 +170,7 @@ func (e *taskExecutorImpl) handleActivityTask( | |||
| ctx, cancel := e.newTaskContext(ctx, attr.NamespaceId) | |||
| defer cancel() | |||
|
|
|||
| err = e.historyEngine.SyncActivity(ctx, request) | |||
| _, err = e.shardContext.GetHistoryClient().SyncActivity(ctx, request) | |||
There was a problem hiding this comment.
Will there be additional cost when we always go through history client? Should we still go through history engine if the request is for the local shard?
There was a problem hiding this comment.
we can certainly add additional wrapper, but the ROI is low?
There was a problem hiding this comment.
actually, if we decide to do perf optimization, the optimization should be done within the wrapper of client
There was a problem hiding this comment.
actually, if we decide to do perf optimization, the optimization should be done within the wrapper of client
Yes. There will be additional network cost but I don't think it is a concern at this point. I can also add an additional check for now and move it to the wrapper of client.
There was a problem hiding this comment.
Ok Let's leave it for now and address it in case it becomes an issue in prod.
There was a problem hiding this comment.
Will add a TODO there.
* Redirect replication requests when shard count is different
What changed?
Redirect replication requests when shard count is different
Why?
When replicate workflow between different shard count, it requires redirect to different shards.
How did you test it?
Unit tests
Potential risks
Is hotfix candidate?