Github user tzulitai commented on the issue:
https://github.com/apache/flink/pull/5282
Thanks for the review @aljoscha!
I'll proceed to merge this (while addressing your last comment) to `master`
and `release-1.5`.
---
Github user tzulitai commented on the issue:
https://github.com/apache/flink/pull/5282
@aljoscha sorry about the leftover merge markers, I've fixed them now.
---
Github user tzulitai commented on the issue:
https://github.com/apache/flink/pull/5282
@aljoscha I've addressed your comments and rebased the PR. Please have
another look when you find the time, thanks a lot.
---
Github user aljoscha commented on the issue:
https://github.com/apache/flink/pull/5282
Yes, that was my main concern. With a loop it could work, yes. ð
---
Github user tzulitai commented on the issue:
https://github.com/apache/flink/pull/5282
@aljoscha regarding the potential flakiness of the test you mentioned:
I think the test will be stable, as long as the recorded timestamp of the
second run is larger than the first run. We can ad
Github user tzulitai commented on the issue:
https://github.com/apache/flink/pull/5282
@aljoscha this is the currently the case for any startup mode. Any
partition discovered after the initial batch fetch is considered a new
partition due to Kafka scale outs, and is therefore read fro
Github user aljoscha commented on the issue:
https://github.com/apache/flink/pull/5282
Initial question: why is the timestamp not used for newly discovered
partitions?
---
Github user tzulitai commented on the issue:
https://github.com/apache/flink/pull/5282
cc @zjureel
---
