De-dup concurrent requests in ramping, current and delete updates #7339
Conversation
| // When a conflict token is provided, we use the hash of the conflict token, deploymentName and the version. This is done | ||
| // to ensure the automatic de-duplication of updates with the same UpdateID. | ||
|
|
||
| combinedBytes := make([]byte, 0, len(conflictToken)+len(deploymentName)+len(version)) |
There was a problem hiding this comment.
I'm thinking it's better to just serialize the whole input and take its hash. It'll be safer for later when more inputs are added. and also it covers the whole request including client identity etc. (I think it client identity is different, we should not de-dup it)
There was a problem hiding this comment.
I'm not sure about including client identity as part of the hash - If two exact requests are coming in from different call sites (hence different identities), we want them to be considered as duped right?
De-dup imo should be based solely on the inputs sent by clients and if the system has already accepted the same set of inputs, why let it do work again to achieve the same state? For requests that do get duped, we are also not returning errors and the right response objects so that calls from a different call site not face any odd errors
What changed?
Why?
updateIDfor those requests where a conflict token is provided or by adding an extra set of protection layer in the update handler.How did you test it?
Potential risks
Documentation
Is hotfix candidate?