Summary

Uri subscriber can receive duplicate uri properties during INDIS migration as both ZK data and Kafka data are input on INDIS Observer (using ZK data to cover server apps that don't emit or partially emit kafka data). Since Kafka data has higher precedence, when Kafka data arrives later than ZK data, it will be sent to the client although the uri properties inside is effectively the same as ZK data, which is still needed, since the metadata is different, like tracing ID, modified time, etc, the client will send tracking events of receipt to track the end-to-end propagation latency for Kafka announcements.

This change only prevents uri subscriber from processing the inner duplicate uri properties as an update, which will prevent all subsequent actions taken by the uri property listeners. (note: there are other edge cases of receiving duplicate uri properties, such as when the version in the uri properties is incremented but the data is unchanged. This change generally protect against all of them and can help us investigate such case in the future)

Testing Done

QEI deployed indis-canary, restart indis-canary backend (which will trigger uri property update with markdowns then back up. When uri is back up, the client will receive it twice), look for logs "received duplicate uri properties" by UriLoadBalancerSubscriber (set log level INFO)

indis-canary.log