Bidirectional Instance data replication faces lag if there is consumer set active in consumer instance but the Producer set is not activeIssue If an Instance have a legacy consumer replication with Active is true, Bidirectional is true, and status is approved, but in the producer instance, the same Producer replication set is not active, the ProducerJob in the consumer instance still tries to connect to the Legacy replication set and increases the lag for other active sets, it might happen even if you have V2 IDR set which is Bi-directional SymptomsYou will see IDR lag keep on increasing and the messages won't be replicatedReleaseAllCause- When you deactivate the producer replication set the consumer replication set is not deactivated automatically - If you do show XML, the active flag is still set to true, and you can see the same from the list view of consumer set replications - and we don't have any option to deactivate the consumer replication set by simply clicking the Deactivate button, we can only delete the replication set - So when the ProducerJob is running, it still checks if the set is Bi-directional, and Active is true, and status is approved, and tries to connect to the topic in the Hermes cluster, which never exist because the Producer instance set is deactivated We see below errors in IDR Replication log table org.apache.kafka.common.errors.TimeoutException: Timeout expired while fetching topic metadata: LogType=IDRLOGS appNode=app00000.dub000.service-now.com:instancename049 IDRLogMessage="null" IDRStackTrace=org.apache.kafka.common.errors.TimeoutException: Topic idr.4d92e891db8bb010b847ac44d4961924.17b63ee547b2051000317ae2846d43ec.f5e81423db9ecfc4a874f897bf9619e4.virtual not present in metadata after 60000 ms.: LogType=IDRLOGS appNode=app0000.dub000.service-now.com:instancename001 IDRLogMessage="JobType=IDRProducerJob ErrorType=TimeoutException" IDRStackTrace=correlationId=0be26351d7644dfd83e279ae97438bf4 correlationPath=0be26351d7644dfd83e279ae97438bf4 org.apache.kafka.common.errors.TimeoutException: Topic idr.4d92e891db8bb010b847ac44d4961924.17b63ee547b2051000317ae2846d43ec.f5e81423db9ecfc4a874f897bf9619e4.virtual not present in metadata after 60000 ms.: LogType=IDRLOGS appNode=app0000.dub000.service-now.com:instancename002 IDRLogMessage="Failed to send payload to MQ with identifier: ReplicatedEntry:{position=[data_replication_queue0001@2025-12-08T03:14:29Z,2032,0,1], action=INSERT_OR_UPDATE, table=idr_system_status, class=idr_system_status, key_field=[sys_id], key_values=[eb6b362ddb3e4114081d4d76059619d7], labels=[LIT-PROD:b9aa3ee5db7e0158309d8c15059619ad]}" IDRStackTrace=ResolutionOption 1) Delete the consumer replications set using the delete option on consumer set Option2) Execute the script below to set the Active flag to false var gr = new GlideRecord('idr_consumer_set');gr.get('SYS_ID of the CONSUMER SET');gr.setValue('active' , false);gr.update(); so the above script will set the Consumer set active flag to false and after that let allow the lag to catch up and that should resolve the issue