Kafka Stream timestamp synchronization in KStream/KTable join with repartitioning - apache-kafka-streams

Question

I need a solution for a Kstream-Ktable join where records will be out-of-order because of preprocessing in topology. I am using kafka-streams:3.0.1
I have topic1 and topic2, if they are keyed on the same key I get the expected result in KStream-KTable join.
T1, T2,..Tn are timestamps.
topic1 records: [{K1,V1}(T2), {K2,V2}(T4)]
topic2 records: [{K1,A}(T1), {K2,B}(T3)]
join result: [{K1,A}, {K2,B}]
KStream stream = builder.stream("topic1");
KTable table= builder.table("topic2");
stream.leftJoin(table, (v1,v2)->v2)
.to("enrichedTopic");
But, if there is pre-processing in topology which results in repartition, the result will not be the same.
topic1 records: [{K1,V1}(T2), {K2,V2}(T4)]
topic2 records: [{*K1,A}(T1), {*K2,B}(T3)]
KStream stream = builder.stream("topic1");
KTable table= builder.stream("topic2")
.selectKey((k,v)->k.replace("*","") //remove '*' from the key
.repartition()
.toTable();
stream.leftJoin(table, (v1,v2)->v2)
.to("enrichedTopic");
Below are two solutions with their disadvantages. I want to know if there is any better way to achieve this.
Solution 1: Increasing max.task.idle.ms
This gives the right result, but I am afraid that it will slow down the processing if topic2 has slow incoming traffic. As join will wait for topic2 partitions data.
Solution 2: Foreign key join
Not completely sure about the result, as it also involves repartitioning. But, it will also produce an increased number of result if have frequent updates on topic2 for the same key and one record from topic2 is mapped to multiple records of topic1 (topic:topic1 is 1:n).
This will also need a logic to remove the records produced by updates on topic2 as we are only interested in value of topic2 when there is an event on topic1 based on time synchronization.
Please correct if there is anything incorrect in my understanding.
Questions:
Let know me if there is any better approach to solve this.
Will solution 2 guarantee the correct result if we only consider the first resultent record produced by a foreign key join (in order to ignore the updates from topic2)?